プログラマーは、他の誰かの失敗したビルドを修正する必要がありますか？[閉まっている]

あるプログラマーはSVNリポジトリーにいくつかの作業をコミットしてから帰宅しました。彼が去った後、ハドソンの自動ビルドは失敗しました。別のプログラマーはこれを見て、コードの変更を調べた後、問題が1つのライブラリーがないことを検出しました。彼はこのライブラリをSVNに追加し、次のビルドが正常に完了しました。

2番目のプログラマーは正しいことをしましたか、それとも最初のプログラマーが問題を解決するまで待つべきでしたか？

チームが通常どのように機能するかにある程度依存しますが、私はそれで良かったと思います。ビルドを機能させ続けると、他のすべての人の時間を節約できます。

特定のバージョンのライブラリが必要な場合や他の複雑な問題が発生した場合に備えて、2番目のプログラマが最初に自分が行ったことを説明するメールをドロップすることは丁寧です。また、彼らがビルドを壊したことを指摘する少し微妙な方法です。

場合によります。

• バグは非常に明白であるため、ライブラリを追加することで修正できますか？時々、修正はそのライブラリを必要としない回避策を見つけることにあります。

• プロジェクトは、すべての変更を既存のチケットにリンクする必要がある段階ですか？ある場合、チケットを提出しましたか？そのチケットはあなたに割り当てられましたか？

とにかく、責任者を非難するのではなく、バグの修正に集中してください。

はい、大丈夫です。ただし、ビルドがコンパイルされるかどうかをテストする前に、元のプログラマが家に帰るのは専門的ではありません。

あなたの評判はあなたのコントロールで100％です。このようなものはあなたの評判を傷つけ、傷ついた評判を磨こうとすることは非常に困難です。

通信する

これらのシナリオには、厳密なルール（チームルール以外）はありません。

Dev2はdev1にエラーを修正できることを伝えることができるはずです。どちらも、この交換の結果として生じる何かを恐れてはならず、チームの一員です。

何故なの？あなたの製品が非難の修正よりも重要であれば、それは確かに大丈夫です。ライブラリの変更が原因でビルドが失敗するのはかなり不十分であり、テストしないために開発者を責める必要があります。

ビルドの失敗が発生します。毎日のビルドが発生することが重要な場合は、修正してから、破損したコードをチェックインした開発者に、翌日修正を確認し、コードが現在どおりになっていることを確認するように依頼します。

既に述べたように、それを修正した人は、おそらくそれを破った人に電子メールを送信し、修正内容を詳しく説明する必要があります。

私のモットーは、午後3時以降にSVNにコミットしないことです。そうすれば、常に自分のビルドの失敗を修正できます。

ビルドの失敗を修正しないと、他のすべてのビルドも失敗します。長期的には時間を節約するために修正しますが、修正する必要があることを彼らが認識していることを確認してください。

何らかの「非難の指を指す」スクリプトを作成することは、これを行うための良い方法です。

誰かがそれを修正する必要があり、最初のプログラマーは最初にビルドを壊していないことを確認せずに家に帰るべきではありませんでした。ただし、このような簡単に修正できる問題の場合、彼に電話をかけて自分で修正するのは極端です。

私はルーク・グラハムの説明的な電子メールの送信の提案に同意しますが、それは丁寧なもの以上のものであると言えます-それは基本的なコミュニケーションです。

はいはいはい！集団的なコードの所有権を促進し、チームに一種の健全な仲間からの圧力をかけ、高水準を維持し、壊れたウィンドウシナリオを開発させないようにします。他の開発者に知らせるための少しのコミュニケーションは良い考えです。

明らかなものを修正してもいいと思います-つまり、修正しようとしているコードを持っている人が同じ-または実質的に同じ-修正することを100％確信しているなら。修正がより複雑な場合は、通常、修正しようとしているコードの担当者と話すのが丁寧です-意図を誤解したか、破損の理由が思ったものではないか、または別の修正を意図している可能性がありますしかし、何らかの理由でまだコミットできませんでした（人生は起こります、あなたは知っています:)。

通常、ルールは通常、次のとおりです。ビルドを中断します-ビルドを修正しますが、特に修正が明らかである場合や責任者に連絡できない場合は例外があります。

もちろん、シリアルビルドブレーカーの場合、特に「チェックイン、帰宅、数日間ビルドが壊れる」パターンの場合、責任者はCIシステムとテストが存在する理由とその方法について話し合う必要があります。チェックインする前にチェックしてください:)

物事が起こります。新しいコードファイル（ソースまたはコンパイル済み）をSubversionに追加できないことは、おそらく開発者のコ​​ンピューターで動作すると仮定した場合、ビルドが破損する最も一般的な原因です。CI環境での私の最後の仕事で、最も年上の人でさえ忘れることがありました。

他の人がビルドを修正して、チームをハミングさせ続けることができたなら、それでいいと思います。家に帰ったプログラマーは、少なくとも何が起こったのかを示すフレンドリーな電子メールを必要とし、コミットする前に新しいコードが追加されることを彼に思い出させる必要があると思います。頻繁に発生する場合は、発生を減らす（および気分を明るくする）ために、「恥の踊り」によって罰せられる軽微な犯罪とすることができます。

それはチームのダイナミクスに依存しますが、理想的な世界では、チームの全員がプロジェクト全体、すべてのコード、そして結果としてすべてのバグを共同で「所有」します。そのため、問題が見つかった場合は修正し、その際にコードに特定の付加価値がある場合にのみ、バグの発生者と通信します。

これが定期的に発生する場合を除き、修正しても構いません。その場合、上司に電話してもらい、彼に戻って自分で修正してもらいます。

それは依存します、依存します...

プログラマーとして、私たちの仕事は物事を機能させることであり、人を判断することではありません。だから私はあなたができる最善のことはそれを修正することだと思います、またはそれが明らかでない場合は、変更をロールバックし、最初のプログラマに後で修正できるように知らせてください。

とにかく、ビルドを壊して変な帽子をかぶる最新の男がいれば、次回はもっと注意を払うのに十分です^ _ ^

一部の環境では、これは非常に失礼であり、正当な理由があります。他の環境では、それが期待され、正当な理由があります。

さらに他の環境では、非常に失礼であるか、非常に悪い理由で予想されます。

それは、破損したビルドがどれほど重要か、検証済みの正しいビルドがどれほど重要かによって大きく異なります。そして、ある程度、修正が適切な修正であり、唯一の修正が必要であることがどれだけ明白かによって異なります。

まず、「帰宅」は時代錯誤です。プログラマーはもう家に帰りません-彼らはただオンラインかオフラインのどちらかです。pingして待機できます。

さらに深刻なのは、実際には2つの問題があります。「コードの変更を確認する」ことは問題ありません。休息は正しいことではないかもしれません。図書館の行方不明の判断が間違っていた場合