コミットがリグレッションを引き起こしたことを誰かに伝える必要がありますか？

退行を追跡して修正すると（つまり、以前は動作していたコードの動作を停止させていたバグ）、バージョン管理により、それを破った変更をコミットしたユーザーを完全に検索できます。

これをする価値はありますか？これをコミットした人に指摘することは建設的ですか？ミスの性質（変更したコードの基本的な誤解に対する単純な不注意の規模）は、それが良いアイデアであるかどうかを変えますか？

彼らに伝えるのが良い考えであるなら、攻撃を引き起こしたり、彼らを守らせたりせずにそれをする良い方法は何ですか？

議論のために、バグはCIサーバーの自動テストで検出できないほど微妙であると仮定します。

あなたがちょうど彼らに近づいたなら、彼らが犯した間違いについて彼らに伝えると、あなたが世界で最高の外交官でない限り、「ハ！-あなたが犯したこの間違いを見てください！」私たちは皆人間であり、批判をとることは困難です。

一方、変更が完全に些細で明らかに間違っていない限り、私は通常、何が起こっているのかを完全に理解していることを確認するために、私の調査の一環として元の変更を行った人と話すことが有益であることがわかりますこれらの状況に対処するには、その人に話を聞き、次のような会話を行います。

私：私はこのバグに取り組んでいます...バグの概要...そして、あなたが行った変更まで問題を追跡したと思います。この変更の目的を覚えていますか？/この変更について説明する時間がありますか？

その後、次のいずれか：

それら：確かに、それは...私が知らなかった状況を処理することです...

または次のようなもの：

それら：いいえ、すみません、覚えていません、私には間違っているようです。

変更/バグを一緒に調査することで、元のコミッターは、彼らが批判されているように感じることなく、自分の過ちから学ぶことができます*。

元のコミッターがいない場合や忙しい場合は、常に自分自身を徹底的に把握して把握することができます。通常、最初に変更を行った人と話す方が速いことがわかります。

* もちろん、他の人の助けに本当に興味がある場合にのみ機能します。もしあなたが彼らが犯した間違いについて誰かに伝えるために、ちょっと偽装した方法としてこれを使用しているなら、これはおそらくそれについてただ開かれているよりも悪いでしょう。

積極的ではなく断定的である。「このコードは機能していません」と「あなたのコードは機能していません」に似たものを言うことを常に優先してください。コードを書いた人ではなく、コードを批判してください。

さらに良いのは、ソリューションを考えることができる場合、それを修正してプッシュします-分散バージョン管理システムがあると仮定します。次に、修正したバグに対して修正が有効かどうかを尋ねます。全体として、あなたと彼らのプログラミングの知識の両方を増やしてください。しかし、あなたのエゴが邪魔されずにそれをしてください。

もちろん、同じ問題を抱えてやってくる他の開発者の話を聞いて、彼らが望んでいた通りに振る舞うようにすべきです。

はい、常に。プログラマーとして、間違いから学ぶのはあなたの仕事です。

彼らが犯した間違いを彼らに知らせることは、彼らがより良いコーダーになり、将来間違いを犯す可能性を減らすのに役立ちます。しかし、丁寧であり、大したことはしません。私たちは皆、頻繁にバグを作成します。丁寧なメールは、人々に知らせるための非常に非対立的な方法だと思います。

建設的な方法は、バグを見つけて修正し、同様のバグが将来発生するのを回避するためのアクションを実行することです。

バグを持ち込まない方法を人々に説明する必要がある場合は、それを試してください。

かつて、私はプロジェクトマネージャーが特定の開発者に間違いを犯したことを決して伝えなかったチームで働いていました。そのような間違い。そのようにして、誰も非難されませんでした。

一般に、はい。

あなたがそれについて気が利いていれば、誰も守ってはいけません。それを処理する簡単な方法は、トランク（またはバージョン管理システムに関連するもの）にコミットする前に、変更を再確認するよう依頼することです。明らかなエラーを修正して数分保存すれば人々は感謝しますが、壊れていないものを修正してコードを壊してしまうと感謝しません。あなたの変更をレビューする機会を与えることで、あなたは彼らのつま先を踏んだくないことを伝え、あなたの変更に反対する機会を与えます。

単なるタイプミスではなく大きな変更である場合は、修正しようとする前に作者に注意を向けることをお勧めします。「ジョー、昨日自分のものをマージして、わからないことを見つけました。それはバグのように見えますが、コードをいじる前にそれを実行したかったのです。ご覧ください。私？」

著者との関係は大きな要因です。作者があなたに告げずにコードを修正することを気にしないなら、そしてその気持ちが相互に確信しているなら、それは言及する価値がないかもしれません。より多くの経験/シニア/ステータスを持っている人なら、あなたは彼らにコードを変更するつもりであることを知らせたいと思うでしょう。それが少ない人であれば、間違いを繰り返さないようにするために聞く必要があるのか​​、それとも不必要に恥ずかしいかもしれません。

「バグ」をチェックインした人を見つけることができれば、コードを「修正」した人を簡単に見つけることができることを常に覚えておいてください。事後の変化を知ることに動揺/困惑/恥ずかしそうだと思う場合は、必ず事前に伝えてください。

また、バグの修正が唯一の選択肢ではありません。いつでも問題トラッカーでバグを報告できます。ここでもタクトが必要です。バグを報告することでチーム全体がより目立つようになりますが、著者は自分の間違いを修正する機会も与えられます。問題を解決する最善の方法が分からない場合、または問題を解決する時間がない場合は、レポートが最適なオプションです。

バグを含むコミットを行う場合は、教えてください。バグを含むあなたのコミットを見つけた場合、必ずお知らせします。

エラーを理解したときにのみ改善します。これが、将来的により良いコードを生成する方法です。

あなたはここで優れた答えを得ています。

ミスを犯したときに、マネージャーから学んだテクニックを一度だけ追加できました。

私は博士号を持つ中年のコンサルタントでした。彼女は若いマネージャーであり、名声の勾配が知覚された可能性がありました。とにかく、彼女は明らかにこの状況を経験しており、その対処方法を知っていました。

彼女は、問題があるように思われるとほぼ謝罪的な口調で私に言いました、そして、私はそれを調べる時間があるでしょうか？

多くの場合、エラーは私のものであり、彼女はそれを知っていました。それがスキルです。

この質問の根底にはさらに深い問題があると思います。はい、提出者は変更の結果を確実に認識して、何が起こったかを理解し、同じことを二度としないようにする必要があります。ただし、質問の内容は、元の送信者が問題を引き起こしたことさえ知らずに修正を準備して送信したことを示しています。その中で、より深い問題がある：なぜ提出者はすでに回帰について知っていないと、なぜ彼らは自分自身それを修正しませんでしたか？あなたが説明した状況は、最初の提出者が説明責任や警戒心を欠いていることを示している可能性があります。

私のソフトウェアエンジニアリングの経験は、私が担当するプロジェクトだけでなく、生産までのすべてのコード変更を所有することを教えてくれました。これには、ビルドシステムや（明らかに）製品の動作など、その影響を認識することも含まれます。

誰かの変更が問題を引き起こした場合、それはその人が悪いエンジニアであることを意味しませんが、通常、彼らは何が間違っているかを修正することに責任があり、関与するべきです。彼らが「過失」ではない場合、たとえばコードが長年にわたってコードベースに存在する根本的なバグを暴露したとしても、彼らは彼らの変更に関する問題を知っている最初の人々の一人であるべきです。元の提出者がバグを修正するのにふさわしくない場合でも、変更のライフサイクルと密接に関連している必要があります。

あなたの質問に良い牽引力！誰もがあなたに何をするかを教えてくれました。教えてください はい！質問が「もっとコミュニケーションをとるべきか？」と尋ねるときはいつでも、答えはほとんど常にYESです！

しかし、別の何かを追加するには：あなたの前提に欠陥があります。

同僚がコミットを行いましたが、CIを壊すことはありませんでしたが、問題を発見することになります。

おめでとうございます！回帰ではなく、新しいバグが見つかりました。真剣に、コミットするときに、自動化された（または標準化された）テストでカバーされないすべてのシナリオとコード行を手動でテストしますか？

必ず、同僚に修正プログラムに参加してもらい、再度発生しないことを確認するテストを行ってください。あなたは両方のヒーローです！しかし、あなたが言葉や行動のせいにならないようにすれば、最悪の組織病の一つである責任のない責任を果たさなければなりません。

本当に悪党を見つける必要がある場合は、壊れた元のコードをコミットし、疑いを持たない仲間にトラップを残した人について考えてください（明らかに十分なテストカバレッジがありません）。うまくいけばそれはあなたではなかった！

他の人を常にあなたよりも良い人とみなし、常に他の人の良い特性を見て、私も間違いを犯す可能性があることを常に知っています。

それがあなたの二人だけであるときにそれらを教えてください。

あなたが彼に間違いをしたと言ったときに誰かが気分を害したなら、それは彼が彼が地球上で最も賢いと思って間違いを犯していないことを意味し、批判されたとき、彼はポーランドで言ったように、「クラウンは落ちている彼の頭'。

だから、誰かが間違いを犯したと言うことをheしないでください。正常です。誰もが間違いを犯します。何もしない人だけが間違いを犯しません;）

他の人が言ったことに加えて、バグを引き起こしたのは実際に彼らのコミットであることを確認してください。間違いなく自分の間違いを他人のせいにしないでください。どれだけ巧みに彼らに近づいても、彼らがやらなかったことで彼らを責めたなら、あなたは彼らを怒らせます。（他の人のバグを常に非難されている人と言えば、誰かが私のところに来て、私はまったく愚かなことをしたと言って、コミットログを持ち出し、そのコード行に触れた最後の人が私を非難していた人。どういうわけか、私はもともとその線を書いていたので、彼はまだ私のせいだと思っていたようです。

質問に対する上位投票コメントを反映する単一の回答がここに表示されないのはなぜですか？

はい、それについて絶対に伝えますが、チーム全体の前でそれをしないでください

開発者に1：1でアプローチし、バグを指摘します。大したことはしないでください。チーム全体の前でエラーを指摘するのは悪い考えだといつも思っていました。一部の開発者には有効かもしれませんが、すべての人に有効ではなく、悪影響を与える可能性があります。覚えておいて、私たちはどこかで彼らの靴の中にいました、そして、2番目に選ばれた答えが言うように、あなたはあなたの間違いから学びます

私は通常、賛辞から始めてエラーに達すると最もうまくいくと思います...「あなたが実装した修正はうまく機能しますが、x、y、zが壊れているようです」、または「 、b、c、ただし、x、y、zを引き起こしているようです」

簡単な答え：はい。

より長い回答：私の最後の仕事は、アジャイル企業で、CIツールでTDDを使用して、SVNリポジトリにあるものが常に正常に機能するコードであることを確認することでした。何かがコミットされると、TeamCityサーバーがコピーを取得し、コンパイルされ、単体テストを実行しました。また、統合テストを1時間ごとに実行しました。CIが失敗する原因となった何かがコミットされた場合、特定の人によるコミットに基づいてビルドが破損したことを示す電子メールを全員が受け取りました。

それは常にすべてをキャッチしませんでした。残念なことに、コードカバレッジを強制しなかったため、ユニットテストや統合テストで何かがカバーされていても、そのコードを十分に実行できない可能性があります。それが起こると、既知の問題（QAがそれを見つけた場合）または欠陥（ダンダンダン、クライアントがした場合）を修正するタスクを取得した人は、「非難」（各行を最後に変更した人を表示）コードファイル）、原因を特定します。

壊れたコードをチェックインするために誰かを呼び出すことは、必ずしも悪いことではありません。彼らは仕事をきちんと果たせず、彼らまたは誰かが戻って間違いを直さなければなりませんでした。これは常に起こります。取引の規模は、修正がどれだけ簡単か、間違いが問題のコードをコンパイルまたは実行しなかったことを示すかどうか、および企業文化全体に依存します。全体的に重要なのは、間違いを犯した人によって何かが学ばれるということです。同じ人が何度も何度もビルドを中断した場合、その人にはより深い問題に対処する必要があります。常に壊れているビルドは、チームのコミュニケーションまたはプロセスの知識に問題があることを示しています。

はい。コードに加えた修正をレビューするように担当者に依頼してください。時々、他の誰かのバグが実際にはコードのトリッキーな部分であり、バグが単純に修正された場合、他の見えない結果になることがわかった。

プレイには多くの要素があります。

• バグはどれほど深刻ですか？
• あなたとブレーカーの年功関係は何ですか？
• チームの忙しさ/ストレスはどれくらいですか？
• ブレーカーはコードベースの一部またはあなたのもので働いていましたか？
• それが実際のバグであるという確信はありますか？また、修正が正しいという確信はありますか？

問題がマイナー（タイプミス/シンコ/カット＆ペーストのバグ）で、ブレーカーが忙しい仲間であり、問​​題の評価に自信がある場合、おそらく彼らに注意を向ける必要はありません。（例foo.x = bar.x; foo.y = bar.y, foo.z = bar.y）。

他のほとんどの場合、問題に言及することをお勧めします。深刻ではない場合は、彼らがしていることを中断する必要はありません。昼食をとるか、休憩室で彼らにぶつかったときに待ってください。

ただし、エラーの性質が（実装プラットフォーム、ローカルポリシー、またはプロジェクト仕様の）重大な誤解を示している場合は、できるだけ早くそれを表示してください。

評価について確信がない場合は、特に、あなたがよく知っているコードにない場合は、修正をレビューするよう依頼してください。（とにかく、チェックイン前にすべての変更を他の1人がレビューする「コードバディ」ポリシーを開発チームに採用することを強くお勧めします。）

あなたが彼らに話さないとどうなりますか？

短所

彼らはそれが問題を引き起こしていることを理解していないので、他の場所でも同じ間違いをするかもしれません。それだけでなく、同じ間違いを繰り返し修正する余分な時間が必要になります。自分が気づいていない間違いから学ぶことはできません。

第二に、彼らは彼らが彼らよりも良い仕事をしていると思う。人々が自分の問題に気づいていないとき、彼らは彼らがそうでないとき、彼らがうまくやっていると思うことはほとんど非難されることができません。問題が不注意な間違いであっても、間違いに気づいたことを知っている人は、それを少なくします。

次に、誰かがそれを行った人を検索しない場合、常に不注意であるか、製品の基本的な誤解がある特定の問題のある従業員があるかどうかをどのように知るのでしょうか？責任者は、彼または彼女が関連付けられているチームでそれを続けたいですか？

議論せずに修正して先に進んだ場合、本当に修正されましたか？要件が変更されたときに変更する必要があるのはテストです。それがかなりマイナーなタイプミス以外の何かである場合、あなたのどちらかが正しい解決策を持っていると本当に確信できますか？あなたは相談せずに見返りに彼のコードを壊しているかもしれません。

プロ

人々は、自分の間違いを指摘することであなたを困惑させたりイライラさせたりしません。

私は彼らに話すことを強く望んでいますが、うまく、そして個人的にそれをします。公的な屈辱は必要ありません。その人が繰り返し同じ過ちを犯したり、理解不足を示す重大な過ちを犯している場合は、監督者も同様に認識させる必要があります。