開発者が自分のワークステーションで作業する方法に関する標準
私たちは、開発者がプロジェクトの途中で数日間病気になったときに時折発生する状況の1つに遭遇しました。
彼が最新バージョンのコードをコミットしたのか、それともローカルマシンに最新のものが見られるのか、という質問がいくつかありました。お客様への配信は保留中でしたので、待つことができませんでした。彼は戻るために。
他の開発者の1人が彼としてログオンしてワークスペースの混乱を見つけましたが、その多くは同じプロジェクトのものであり、タイムスタンプによって「現在」のものは不明になりました（彼は、彼の「コア」なもの）。
明らかにこれは首の痛みですが、代替案（各開発者がどのように動作するかについての厳密な基準であるように思われます自分のマシン上で他の開発者が最低限のことで物事を拾えるようにします努力）は、多くの開発者の個人的なワークフローを壊し、個人レベルでの非効率につながる可能性があります。
チェックインコードの標準や一般的な開発標準についても話しているのではなく、開発者がローカルでどのように作業しているか、つまり、（私の経験では）開発者自身の制御下にあると一般的に考えられているドメインについて話している。
では、このような状況にどのように対処しますか？発生して対処しなければならないことの1つは、開発者に最適な方法で作業することを許可されている開発者に支払う代償ですか？
それとも、開発者にこの分野の標準に準拠するように依頼しますか-特定のディレクトリ、命名標準、wiki上のメモなどを使用しますか？もしそうなら、あなたの基準は何をカバーしていますか、それらはどの程度厳格ですか、どのようにそれらをポリシングしますか？
または、私が見逃している別の解決策はありますか？
[議論のために、開発者に連絡して、ここで何をしていたかを話すことはできないと仮定します。たとえメモリからどのワークスペースがどのワークスペースであるかを知っていて説明することはできませんが、単純で完璧ではない場合があります。連絡しないでください。すべての不測の事態をカバーする解決策が必要です。]
編集：誰かのワークステーションを通過するのは悪い形だと思います（興味深いのですがそしておそらくオフトピック-正確にはなぜかという質問です）そして私は確かに無制限のアクセスを見ていません。標準に沿って、コードディレクトリが読み取り専用の共有で設定されていることを考えてください。何も変更できず、他に何も表示されないなどです。
"ソース管理にない場合は存在しません。"
これは、私がボーダーラインの独断的である私たちの職業の数少ないものの1つです。以下の理由により：
- ワークステーションは会社の所有物ですが、それに直面しましょう-プログラマー自身のワークステーションが彼/彼女の城であるという、書かれていないルールが少しあります。私は、だれもが日常的にログオンして実行できる職場文化に不安を感じています。
- （あなたも言ったように）誰もが独自のフローを持っています。すべての開発者に特定の方法で自分のローカルワークスペースを整理するように強制しようとすると、特定の作業方法に反し、フローが中断され、効率が低下します。
- ソース管理にないものは中途半端なコードです。リリースの準備が整った完全にベイクされたコードである場合は、ソース管理にする必要があります。これは、要点に戻ります...
- 「それがソース管理にない場合、それは存在しません。」
人々のワークステーションでコードを確認したいという問題を軽減する1つの可能な方法は、定期的なチェックインの文化を育むことです。私はかつてある会社で働いていました-正式な義務はありませんでしたが、週末にすべてを常にチェックインすることは一種の誇りでした。保守フェーズとリリース候補フェーズでは、CRアイテムを意図的に非常に細かくし、小さくてはっきりと見える変更と、定期的なチェックインによってそれらを追跡できるようにしました。
また、休暇に行く前にすべてをチェックインすることは必須でした。
TL; DRバージョン：人のワークステーションを通過するのは不適切です。人々のワークステーションを簡単に通過して必要なものを見つけられるようにする文化を育てるのではなく、賢明なソース管理の使用と定期的なチェックインの文化を育むほうがよいでしょう。場合によっては、非常に定期的なチェックインや、プロジェクトの重要なフェーズでのきめ細かいタスクも可能です。
開発者がワークステーションを編成する方法の標準を適用するのではなく、すべての作業が毎日の終わりにチェックインされる標準を適用します。まだ完了していない場合、チェックインはブランチに対して行われる可能性があります。
これにより、他の開発者のワークステーションにアクセスする必要がなくなります。
このポリシーは何らかの反対に遭遇すると思いますが、ワークステーションの編成に関するルールを適用した場合に予想されるものと比較して、何もありません。
誰かが私のマシンにログインして私のものを閲覧しようとしているというまさにその考えについて私が不安に思う真実をあなたに伝えます。確かに、それは会社の設備と財産ですが、それは単に悪いことです。
前回週末に出発したとき、彼らはデータベースとソースコントロールを使用してサーバーを再構成し、何らかの理由で自分のマシンにログインしてシステムを再構成して新しい設定にする必要があると感じました。
彼らが何をしているのかまったく理解できず、過去2か月間私が作業していたプロトタイプを消去してしまいました。
適切なコミュニケーションが整っていれば、それは起こりませんでした。それも必要です。その開発者に連絡して、物事の状態を調べてください。さらに良いことに、休暇をとる前に人々に報告を求め、彼らが何かを必要とするかどうかについて情報に基づいた決定を下すようにします。
しかし、人々のワークステーションをいじらないでください。
追伸ディレクトリ構造には慣例がありますが、その主な存在理由は、履歴と構成が混在しているためです。他の場所に配置すると、コンパイルされません。
数か月前、私はかなり大きなプロジェクトに取り組んでおり、病院に入院していることがわかったため、突然仕事を辞めなければなりませんでした。プロジェクトの最新コードをチェックインする時間がありませんでした。
幸運なことに、ここでは（「必須」ではありませんが）コードを/var/www/ourdomain.comに格納して本番環境を模倣することが慣例となっています。このような論理的で従うのが簡単な規則により、同僚が私のマシンにログインして最新の変更を取得するのは簡単でした。
いくつかの慣習は良いと思う。彼が言うとき、私はボビーに同意しますが
「ソース管理にない場合、それは存在しません。」
また、すべてのソースおよび開発プロジェクトを保存するためのフロントベイのホットスワップSATAドライブを、プログラマーのワークスペースに追加すると便利です。このようにして、そのような問題が発生した場合、従業員は開発者のワークステーションにログインする必要なく、プロジェクトの新しいソースの変更を簡単に取得できます。
質問の最初の部分では、チーム内のコミュニケーションの問題を明確に特定します。 デイリースタンドアップ を試しましたか？
基準が厳しすぎると基準がおそらく非効率になるとあなたが言うとき、私はあなたに同意します。標準は、teamによって定義され、全員が関与する必要があります。
あなたの場合、関係する開発者が職場に戻ってから数日待ちます。次に、これらの標準について話し合うための会議を開催します。
心理的なブロックや抵抗を避けるために、見た人や特定のものに名前を付けないでください。一般的に言って、ここでの目標は、作業方法を改善する必要があると思われる開発者を含め、すべての人から意見を聞くことです。男もあなたの組織を混乱とみなすかもしれません。
会議中に問題を提示し、チームがどのように状況を改善できるかを明確に尋ねます。
（全体）チームが何をすべきかを決定します。
そのユーザーはおそらく適切なツールの不足に苦しんでいたでしょう。特に、分散バージョン管理システムを使用すれば、異なる状態で異なるコードのディレクトリを用意する必要がなくなります。彼はそれをすべて枝に留めて、はるかに幸せでした。
ただし、要点を述べると、自分のワークステーションをどのように編成するかについて標準を適用したくありません。 IDE（上司は本当に私たち全員をEclipseで望んでいます。それはIMOが最適なツールではありませんが、使用して知っているからです。 myジョブ）。
開発者が快適にできることなら何でもできるようにします。快適な開発者は、不快な開発者よりも生産的です。そして、誰かが生産的ではなく、あなたが彼らがツールを使ってローカルでいじり回していると疑うなら、それはトレーニングの機会であり、新しいルールを作る良い機会ではありません。
私の古い職場では、バグ追跡の各タスクにソース管理の独自のブランチがあるシステムがありました。ほとんどの場合、1つのバグ/タスクが1人の開発者によってつぶされるため、壊れたコードをソース管理にチェックインすることが許可されていました。
コードが開発ブランチで安定した状態になると、統合するブランチからコードをドラッグしてリベースが行われました。いったんそのマージをテストしたら、それは単に統合ブランチにコードをコミットする場合です-ブランチですでにマージを行っているので、マージする必要はありません。
このようにして、壊れたコードをコミットすることを心配する開発者の問題を保存し、夜間にオフィスを離れる前にコードをチェックインすることを非常に許容できるものにするソーシャルポリシーを適用し始めることができます。
this特定の状況で家にいる人に電話し、彼が病気であることを疑っていないが、誰かに彼の仕事を続けさせる必要があること、そして最新のものはどこにあるか尋ねることを非常に明確にしてくださいどのような状態。
次に、ここからどうするかを検討する必要があります。チェックインの頻度があまりにも少ないことが問題である場合は、分散ソース管理システムを使用して、お互いの邪魔をせずにブランチで作業できるようにすることを検討してください。
問題が、マシン上に複数のワークスペースを持つ開発者が嫌いな場合は、それを乗り越えてください。作業スタイルは個人的なものであり、ソースリポジトリのルールで問題なく機能する限り、基本的にはシステムに近づかないでください。個人的に私はさまざまなプロジェクトの新しいコピーを非常に頻繁にチェックアウトし、時々クリーンアップするだけです。
開発者が何をしているかわからないことが問題である場合、問題は技術的ではなく政治的であり、管理のスタイルを変更する必要があります。開発者は非常に熟練した人材であり、マイクロマネージメントはあまり好きではなく、あなたはする必要があるデリゲートであることに注意してください。そうでなければ、最も熟練した個人を押しのけてしまいます。
ですから、共通のソースリポジトリで作業するためのより良い方法を奨励することをお勧めします。ブランチで作業することは問題なく、ローカルコピーをマスターリポジトリに毎日同期している限り、頻繁にコミットできるようにします（常にブランチで開発作業を行いますが、これは他のユーザーには影響しません）。
では、このような状況にどのように対処しますか？
この問題は、個人の不安定なブランチをサポートするソース管理システムを使用して、頻繁にコミットを維持することで解決できます。問題全体が解決されたときにコミットが来る必要はありません。ソース管理の恩恵を受けるときはいつでもそれが来るはずです。 1日の終わりは、変更が行われた場所を確認し、それらをバックアップし、将来の自分や他の人に説明できるように、コミットが発生する多くのポイントの1つです。
それとも、開発者にこの分野の標準に準拠するように依頼しますか-特定のディレクトリ、命名標準、wiki上のメモなどを使用しますか？
標準ではなく、規約を示す膨大な環境設定ドキュメントがあります。標準は、製品コードと環境用です。しかし、私たちの開発ツールの多くは、慣習をサポートするように設定されており、ほとんどの開発者はこの傾向を打ち破る努力を費やしません。