開発者が自分のワークステーションで作業する方法の標準

開発者がプロ​​ジェクトの途中で数日間病気になったときに時々起こるような状況に出くわしたばかりです。

彼が自分のコードの最新バージョンをコミットしたのか、それとも私たちが見なければならないローカルマシンに何か新しいものがあるのか​​どうかについていくつかの質問がありました。彼が戻ってくる。

他の開発者の1人が彼としてログオンして、多くが同じプロジェクトのように見えるワークスペースを見つけて、どれが「現在」であるかが不明確になったタイムスタンプを見つけました（彼は、彼の「コア」1）。

明らかにこれは首の痛みですが、代替策（各開発者が最小の労力で物事を拾うことができるように各開発者が自分のマシンでどのように動作するかについての厳格な基準のようです）開発者の個人的な作業が流れ、個人レベルでの非効率につながります。

私は、チェックインコードの標準や、一般的な開発標準についても話していません。開発者がローカルでどのように動作するかについて話しているのです。

それでは、このような状況をどのように処理しますか？開発者に支払う代価は、彼らに最適な方法で作業することを許可されているのか、あなたが対処しなければならないことの1つですか？

または、開発者にこの分野の標準（特定のディレクトリの使用、標準の命名、Wiki上のメモなど）を遵守するよう依頼しますか？もしそうなら、あなたの基準は何をカバーしていますか、それらはどれくらい厳格ですか、どのようにそれらを取り締まりますか？

または、私が見逃している別の解決策はありますか？

[議論のために、開発者は彼がここで何をしているのかを話すために連絡できないと仮定します-メモリからどのワークスペースがどれであるかを知って記述できたとしても、単純で完璧ではない場合があります連絡しないでください。すべての不測の事態をカバーするソリューションが欲しいです。]

編集：誰かのワークステーションを通過するのは悪い形だと思います（それはなぜ興味深いのか、おそらくトピック外の質問です）、そして無制限のアクセスを見ていません。コードディレクトリが読み取り専用共有でセットアップされている標準のラインに沿ってもっと考えてください-何も変更できず、他に何も見えません。

「ソース管理にない場合は存在しません。」

これは、私が専門分野で私が境界線上の独断的なことをしている数少ないものの一つです。次の理由により：

1. ワークステーションは会社の所有物ですが、それに直面しましょう-プログラマー自身のワークステーションが彼/彼女の城であるという、書かれていない規則が少しあります。誰もが日常的にログオンし、それを通り抜けることができる職場文化には不安があります。
2. 誰もが独自のフローを持っています（あなたが言ったように）。すべての開発者に特定の方法で独自のローカルワークスペースを整理させようとすると、特定の作業方法に逆行し、フローを中断して効率を低下させる可能性があります。
3. ソース管理にないものは、中途半端なコードです。リリースの準備が整った完全にベイクされたコードである場合、ソース管理にある必要があります。これは、要点に戻ります。
4. 「ソース管理にない場合は存在しません。」

人々のワークステーションでコードを見たいという問題を軽減する1つの方法は、定期的なチェックインの文化を育てることです。私はかつて会社で働いていました。公式の義務はありませんでしたが、週末にすべてをチェックインすることは一種の誇りのポイントでした。メンテナンスおよびリリース候補フェーズでは、CRアイテムは意図的に非常にきめ細かく、小さく、きれいに見える変更を可能にし、定期的なチェックインでそれらを追跡します。

また、休暇に入る前にすべてをチェックインすることが必須でした。

TL; DRバージョン：人々のワークステーションでのライフルは悪い形です。人々のワークステーションを簡単に通過して私たちが望むものを見つけるという文化を育てようとするよりも、賢明なソース管理の使用と定期的なチェックインの文化を育てる方がよいでしょう。おそらく非常に定期的なチェックインや、プロジェクトの重要な段階にあるきめ細かなタスクも可能です。

開発者がワークステーションを整理する方法の標準を実施するのではなく、毎日の終わりにすべての作業がチェックインされる標準を実施します。チェックインは、まだ完了していない場合はブランチに行うことができます。

このようにして、他の開発者のワークステーションにアクセスする必要はありません。

私はこのポリシーが反対に出会うことを想像しますが、ワークステーションの組織に関する規則を実施した場合、私が期待するものと比べて何もありません。

誰かが私のマシンにログインして自分のものを閲覧しようとしているという考えに不安を感じる真実をお話しします。確かに、それは会社の機器と財産ですが、それは単に悪いことです。

前回私が週末に去ったとき、みんなはデータベースとソース管理でサーバーを再構成し、何らかの理由で私のマシンにログインして新しい設定のためにシステムを再構成する必要があると感じました。

残念なことに、彼らは自分たちが何をしているかわからず、過去2か月間作業していたプロトタイプを消してしまいました。

適切なコミュニケーションが整っていれば、それは起こりませんでした。それもあなたが必要とするものです。その開発者のところに行き、物事の状態を調べてください。さらに良いのは、休暇をとる前に人々に報告を求めて、あなたが彼らの何かが必要かどうかについて十分な情報に基づいた決定を下すようにすることです。

しかし、人々のワークステーションを台無しにしないでください。

PSディレクトリ構造には慣習がありますが、主な存在理由は履歴/構成の混合です-他の場所に置くとコンパイルされません。

数ヶ月前、私はかなり大きなプロジェクトに取り組んでいたため、病院に入院していることがわかったため、急に仕事を辞めなければなりませんでした。プロジェクトの最新コードをチェックインする時間がありませんでした。

幸いなことに、コードを保存し/var/www/ourdomain.comて本番環境を模倣することは（「必須」ではありませんが）ここでは慣例です。このように論理的で従うのが簡単な慣例により、同僚が私のマシンにログインして最新の変更を取得するのは簡単でした。

いくつかの慣習は良いと思います。ボビーが言うときは同意しますが

「ソース管理にない場合は存在しません。」

また、すべてのソースプロジェクトおよび開発プロジェクトを保存するフロントベイホットスワップSATAドライブは、プログラマワークスペースへの便利な追加機能です。このように、このような問題が発生した場合、従業員は開発者ワークステーションにログインする必要なく、プロジェクトの新しいソースの変更を簡単に取得できます。

質問の最初の部分では、チーム内のコミュニケーションの問題を明確に特定します。毎日のスタンドアップを試しましたか？

基準が厳しすぎると非効率になる可能性が高いと言うとき、私はあなたに同意します。基準は、全員が関与するチームによって定義されなければなりません。

あなたの場合、関係する開発者が職場に戻ってから数日待ちます。次に、これらの標準について話し合う会議を開催します。

心理的なブロックや抵抗を避けるために、見た人や特定のものに名前を付けないでください。一般的に言って、ここでの目標は、あなたの働き方を改善すべきだと思う開発者を含め、すべての人から意見を聞くことです。男はあなたの組織も混乱していると考えるかもしれません。

会議中に問題を提示し、チームが状況を改善する方法を明確に尋ねます。

（全体の）チームが何をすべきかを決定します。

そのユーザーは、おそらく適切なツールの不足に苦しんでいました。特に、分散バージョン管理システムを使用すると、さまざまな状態のさまざまなコードのディレクトリを用意する必要がなくなります。彼はそれをすべて枝に入れて、もっと幸せになっていただろう。

しかし、要点としては、いいえ、自分のワークステーションをどのように編成するかについて標準が強制されることは望ましくありません。私は現在、部門をIDEで標準化することを後押ししています（上司は、IMOは私の仕事に最適なツールではありませんが、Eclipseを使用し、よく知っているため、私たち全員にEclipseを本当に望んでいます）。

開発者が快適にするために何でもできます。快適な開発者は、不快な開発者よりも生産的です。誰かが生産的でなく、ツールをローカルで手探りしているのではないかと疑われる場合、それはトレーニングの機会であり、新しいルールを作る良い機会ではありません。

私の古い職場では、バグ追跡の各タスクがソース管理に独自のブランチを持つシステムがありました。ほとんどの場合、1人のバグ/タスクが1人の開発者によって押しつぶされるため、破損したコードをソース管理にチェックインできることが理解されていました。

コードが開発ブランチで安定した状態になったら、統合するブランチからコードをドラッグしてリベースしました。そのマージをテストしたら、コードを統合ブランチにコミットするだけのケースになります。ブランチで既にマージを行っているため、マージは必要ありません。

これにより、壊れたコードをコミットすることを心配する開発者の問題を回避できます。また、夜間にオフィスを出る前にコードをチェックインすることを非常に受け入れやすくするという社会的ポリシーを適用できます。

で、この特定の状況コール自宅で一人、あなたは彼が病気であることを疑っていないこと、それは非常に明確にしていますが、他の誰かを持っている彼の仕事を続け、そして最新のものであり、どのような状態でどこに依頼する必要があります。

次に、ここから何をすべきかを検討する必要があります。チェックインがあまり行われないという問題がある場合は、互いに干渉することなくブランチで作業できる分散ソース管理システムの使用を検討してください。

問題が、開発者がマシン上に複数のワークスペースを持っているのが気に入らないという場合、それを乗り越えてください。作業スタイルは個々のものであり、ソースリポジトリのルールで正常に機能する限り、基本的にシステムから離れる必要があります。個人的には、さまざまなプロジェクトの新しいコピーを頻繁にチェックアウトし、たまにクリーンアップするだけです。

開発者が何をしているのかわからないという問題がある場合、問題は政治的なものではなく技術的なものであり、管理スタイルを変更する必要があります。開発者は非常にスキルの高い個人であり、マイクロ管理があまり好きではないため、委任する必要があることに注意してください。そうでなければ、あなたは最も熟練した個人を押しのけます。

そのため、共通のソースリポジトリで作業するためのより良い方法を奨励することをお勧めします-ブランチで作業することは問題ないと言い、ローカルコピーを毎日マスターリポジトリに同期する限り、頻繁にコミットさせます常にブランチで開発作業を行いますが、これは他に影響を与えません）。

それでは、このような状況をどのように処理しますか？

この問題は、個人の不安定なブランチをサポートするソース管理システムを使用して、頻繁なコミットを維持することで解決できます。問題全体が解決されたときにコミットを行う必要はありません。ソース管理の恩恵を受けるたびに来るはずです。1日の終わりは、変更が行われた場所を確認してバックアップし、将来の自分や他の人に説明できるように、コミットが発生する多くのポイントの1つです。

または、開発者にこの分野の標準（特定のディレクトリの使用、標準の命名、Wiki上のメモなど）を遵守するよう依頼しますか？

規約を示すが標準ではない巨大な環境設定ドキュメントがあります。標準は、実動コードおよび環境用です。ただし、当社の開発ツールの多くは慣習をサポートするように設定されており、ほとんどの開発者はトレンドに逆らう努力をしません。