プログラマは他の誰かの失敗したビルドを修正する必要がありますか？
1人のプログラマーがSVNリポジトリーにいくつかの作業をコミットした後、家に帰りました。彼が去った後、ハドソンの自動ビルドは失敗しました。別のプログラマーがこれを見て、コードの変更を調べたところ、問題は1つのライブラリーがないことであることがわかりました。彼はこのライブラリをSVNに追加し、次のビルドは正常に完了しました。
2人目のプログラマーは正しいことをしましたか、それとも1人目のプログラマーが問題を修正するまで待つべきでしたか？
それはあなたのチームが通常どのように機能するかにある程度依存しますが、私はそれは大丈夫だったと思います。ビルドを機能させ続けることで、他のすべての人の時間を節約できます。
ライブラリの特定のバージョンが必要になったり、他の問題が発生したりした場合に備えて、2番目のプログラマが最初のメールをドロップして何をしたかを説明するのは丁寧です。また、ビルドが壊れていることを指摘するためのやや微妙な方法でもあります。
場合によります。
ライブラリを追加することがバグを修正する方法であるほどバグは明白ですか？時々修正は、そのライブラリを必要としない回避策を見つけることです。
プロジェクトは、すべての変更を既存のチケットにリンクする必要があるフェーズにありますか？もしそうなら、あなたはチケットを提出しましたか？そのチケットはあなたに割り当てられましたか？
とにかく、責任を責めるのではなく、バグの修正に集中してください。
はい、大丈夫です。ただし、ビルドがコンパイルされるかどうかをテストする前に、元のプログラマが家に帰るのは専門的ではありません。
あなたの評判はあなたの支配下で100％です。このようなものはあなたの評判を傷つけ、傷ついた評判を磨くことは非常に困難です。
通信
これらのシナリオには（自分のチームルール以外に）厳密なルールはありません。
Dev2は、自分のエラーを修正できることをdev1に伝えることができるはずです。どちらも、この交換の結果として何かを恐れるべきではなく、チームの一部です。
何故なの？あなたの製品が非難を修正することよりも重要であるならば、それは確かに大丈夫です。ライブラリの変更が原因でビルドが失敗するのはかなり不十分ですが、テストしないように開発者に叱責する必要があります。
ビルドの失敗が発生します。毎日ビルドを行うことが重要な場合は、それを修正してから、壊れたコードをチェックインした開発者に翌日修正をレビューして、コードが現状どおりであることを確認するように依頼します。
言われたように、それを修正した人はおそらくそれを壊した人にメールを送って、修正が何であったか詳細を伝えるべきです。
はいはいはい！集団的なコードの所有権を育成し、チームに一種の健全なピアプレッシャーを設定して、高水準を維持し、壊れたウィンドウのシナリオが発生しないようにします。他の開発者に知らせるちょっとしたコミュニケーションは良い考えです。
明らかなことを修正しても問題ないと思います。つまり、修正しているコードの人が100％確実であれば、修正するコードは同じか、実質的に同じです。修正がさらに複雑な場合は、通常、修正するコードの担当者と話すのは丁寧です-意図を誤解しているか、破損の理由が意図したものと異なるか、または別の修正を意図している可能性があります。しかし、何らかの理由でそれをまだコミットできませんでした（人生は起こります、あなたは知っています:)。
一般に、ルールは通常、次のとおりです。ビルドを中断します-ビルドを修正しますが、特に修正が明白であるか、責任者が到達できない場合は、例外があります。
もちろん、シリアルビルドブレーカーのケースがある場合-特に「チェックインして家に帰り、ビルドが数日間壊れる」というパターンの場合-責任者は、CIシステムとテストが存在する理由とその方法について話し合う必要がありますチェックインする前にチェックしてください:)
私のモットーは、午後3時以降はSVNにコミットしないことです。そうすることで、いつでも独自のビルドエラーを修正できます。
ビルドの失敗を修正しないと、他の人のビルドもすべて失敗します。長期的には時間を節約するために修正しますが、修正する必要があることを彼らが認識していることを確認してください。
なんらかの「非難の指を向ける」スクリプトを持つことは、これを行う、またはビルドを壊す人にドーナツを購入させる良い方法です!!
誰かがそれを修正する必要があり、最初のプログラマーは、ビルドを壊していないことを確認せずに家に帰るべきではありません。ただし、このように簡単に修正できる問題の場合、自分で修正するように彼に電話をかけるのは極端です。
説明メールを送信するというルークグラハムの提案に同意しますが、それは礼儀以上のものであると言えます-それは基本的なコミュニケーションです。
物事が起こります。新しいコードファイル（ソースまたはコンパイル済み）をSubversionに追加できなかったことが、おそらく開発者のコンピューターで機能すると想定して、ビルドが壊れる最も一般的な原因です。 CI環境での最後の仕事で、最年長の人でさえ時々忘れました。
別の人がビルドを修正して、チームが口ずさむことができたとしても、それは問題ないと思います。私は家に帰ったプログラマーには少なくとも何が起こったのかを伝える友好的な電子メールが必要であり、コミットする前に新しいコードが追加されることを確認するように彼に思い出させると思います。頻繁に発生する場合は、「恥のダンス」で軽犯罪を処罰して、発生を減らし（気分を明るく）してください。
それはチームのダイナミクスに依存しますが、理想的な世界では、チームの全員がプロジェクト全体、すべてのコード、そしてその結果としてすべてのバグを共同で「所有」します。したがって、問題を見つけた場合は修正し、コードに特定の付加価値がある場合にのみ、バグの発信者と連絡を取ります。
これが定期的な出来事でない限り、修正しても問題ありません。その場合、上司に電話をかけてもらい、彼に戻って自分で修正させます。
状況次第です...
プログラマーとしての私たちの仕事は、人を判断することではなく、物事を機能させることです。だから私はあなたができる最善のことはそれを修正することです、またはそれが明らかでない場合は変更をロールバックして最初のプログラマーに知らせて後で修正できるようにするといいでしょう。
とにかく、奇妙な帽子をかぶるためにビルドを壊した最新の男がいることは、次回にもっと注意を払うのに十分です^ _ ^
一部の環境では、これは非常に失礼で、正当な理由があります。他の環境では、それは当然のことであり、当然のことです。
さらに他の環境では、それは非常に失礼または非常に悪い理由で予期されています。
これは、壊れたビルドがどれほど重要であるか、検証済みの正しいビルドがどれほど重要であるかによって大きく異なります。そして、ある程度は、修正が適切な修正であり、必要な唯一の修正であることがどれほど明白であったかによって異なります。
まず、「家に帰った」とは時代錯誤です。プログラマーはもう家に帰らず、単にオンラインかオフラインのどちらかです。あなたはpingして待つことができます。
もっと真剣に、質問には実際には2つの部分があります。 「コード変更の確認」は問題ありません。残りは正しいことではないかもしれません。ライブラリーがないという彼の判断が間違っていた場合はどうなりますか？