私は誰かに彼らのコミットが後退を引き起こしたと伝えるべきですか？
回帰を追跡して修正するとき、つまり以前は機能していたコードが機能しなくなったバグ-バージョン管理により、コードを壊した変更を誰がコミットしたかを完全に調べることができます。
これを行う価値はありますか？これをコミットした人に指摘することは建設的ですか？間違いの性質（変更されたコードの根本的な誤解に対する単純な不注意の規模で）は、それが良いアイデアであるかどうかに関係なく変化しますか？
彼らに告げるのが良い考えであるならば、攻撃を引き起こしたり、彼らを防御させたりせずにそれを行う良い方法は何ですか？
議論のために、バグがCIサーバーの自動テストで検出できないほど微妙であると想定します。
彼らが犯した間違いについて彼らに話しかけるだけの場合、あなたが世界で最も優れた外交官でない限り、「ハ！-あなたが犯したこの間違いを見てください！」のように聞こえるのは難しいでしょう。私たちは皆人間であり、批判を受けることは困難です。
一方、変更が完全に取るに足らないものであり、明らかに誤りでない限り、通常、元の変更を行った人に調査の一環として話をして、何が起こっているのかを完全に理解していることを確認するのは有益です。したがって、私が通常これらの状況を処理する方法は、その人のところに行って、次のような会話をすることです。
Me：このバグに取り組んでいます...バグの概要...そして私は問題を追跡して変更を加えました。この変更の目的を覚えていますか？ /この変更について説明する時間はありますか？
次に、いずれか：
Them：もちろん、それで処理できます...気づかなかった状況...
または次のようなもの：
Them：申し訳ありませんが、覚えていません。
変更/バグを一緒に調査することで、元のコミッターは批判されているように感じることなく、間違いから学ぶことができます*。また、何かを学ぶ可能性もかなりあります。
元のコミッターがいない場合や忙しい場合は、通常、ログインしてすべてを把握することができます。通常、最初に変更を行った人と話す方が早いことがわかります。
*もちろん、これは、他の人の助けに本当に興味がある場合にのみ機能します。これを、誰かが犯した間違いについて誰かに伝える偽装した方法として使用している場合、これは単にそれについてオープンであることよりも悪いです
積極的ではなく積極的になります。 「このコードは機能していません」と「あなたのコードは機能していません」のようなものを言ってください。コードを書いた人ではなく、コードを批判してください。
さらに良いのは、もしあなたが解決策を考えることができれば、それを修正してそれらにプッシュすることです-分散バージョン管理システムがあると仮定してください。次に、あなたの修正が彼らが修正していたバグに対して有効かどうかを尋ねます。全体として、あなた自身と彼らのプログラミングに関する知識の両方を増やすようにしてください。しかし、あなたの自我が邪魔にならないようにしてください。
もちろん、あなたは同じ問題を抱えてやって来る他の開発者の話を聞いて、彼らがそうしたいと望んでいたであろう方法で行動することをいとわないでしょう。
はい、常に。プログラマーとして、間違いから学ぶことはあなたの仕事です。
彼らが犯した間違いを彼らに知らせることは、彼らがより良いコーダーになるのを助け、将来間違いを犯す可能性を減らします。 [〜＃〜] but [〜＃〜]礼儀正しく、大したことはしないでください。私たちは皆、頻繁にバグを作成します。丁寧なメールは、人に知らせる非常に非対立的な方法だと思います。
建設的な方法は、バグを見つけて修正し、同様のバグが今後発生しないようにアクションを実行することです。
バグを導入しない方法を人々に説明する必要がある場合は、それに進んでください。
かつて、プロジェクトマネージャーが特定の開発者に間違いを犯したことを決して伝えなかったチームで働いていました。彼はチーム全体と会議を開き、間違いがあったこと、および抑制するために新しいプロセスが定義されていることを説明しましたそのような間違い。そのように、誰も非難されませんでした。
一般的に、yesです。
あなたがそれについて巧妙であるならば、誰も守備になるべきではありません。これを処理する簡単な方法は、変更をトランク（またはバージョン管理システムに関連するもの）にコミットする前に、変更を再確認するように依頼することです。明らかなエラーを修正して数分保存すると、人々はそれを高く評価しますが、壊れていないものを修正してコードが壊れてしまうと、人々はそれを評価しません。彼らにあなたの変更をレビューする機会を与えることは、あなたが彼らのつま先を踏みたくないことを彼らに伝え、あなたの変更に反対する機会を彼らに与えます。
単なるタイプミスではなく大きな変更である場合は、修正を試みる前に、作者に注意を喚起することをお勧めします。 「ジョー、私は昨日、自分のものをマージしていて、よくわからないものを見つけました。バグのように見えますが、コードをいじる前に、あなたが実行したかったのです。調べてみますか？私？」
著者との関係は大きな要因です。作者があなたに言わずにコードを修正することを気にせず、感情が相互に関連していると確信している場合は、言及する価値がないかもしれません。それがより多くの経験/年功/ステータスを持つ誰かであるならば、あなたは彼らに彼らのコードを変更しようとしていることを彼らに知らせたいでしょう。それが少ない人であれば、それが間違いを繰り返さないために聞く必要のある種類のことなのか、それとも不必要に困惑させるのかを検討してください。
誰が「バグ」にチェックインしたかを見つけることができれば、誰がコードを「修正」したかを簡単に見つけることができることを常に覚えておいてください。事後の変化について知り、動揺/困惑/困惑すると思うなら、必ず事前に伝えてください。
また、バグを修正することが唯一の選択肢ではありません。あなたはいつでもあなたの課題追跡にバグを報告することができます。ここでもタクトが必要です-バグを報告することでチーム全体にわかりやすくなりますが、作成者は自分の間違いを修正する機会も得られます。問題を修正する最善の方法がわからない場合、または問題を修正する時間がない場合は、レポートが最適なオプションです。
バグを含むコミットを行う場合は、教えてください。バグを含むあなたのコミットを見つけたら、きっと教えます。
エラーを理解したときにのみ改善します。これが、将来、より良いコードを生成する方法です。
ここで優れた答えを得ています。
マネージャーから学んだテクニックは、間違えたときに一度だけ追加できました。
私は博士号を持つ中年コンサルタントでした。そして彼女はそれなしでは若いマネージャーだったので、知覚された名声の勾配があったかもしれません。とにかく、彼女は明らかにこの状況の経験があり、その対処方法を知っていました。
彼女はほとんど謝罪の口調で問題があるように思われました、そして私はそれを調査する時間がありますか？
多くの場合、エラーは私のものであり、彼女はそれを知っていました。それがスキルです。
この質問の根底にはもっと深い問題があると思います。はい、送信者は変更の結果を確実に認識しておく必要があります。これにより、送信者は何が起こったのかを理解し、同じことを繰り返さないようにすることができます。ただし、質問のコンテキストは、youが修正を準備して送信したことを示しています。元の送信者が問題を引き起こしたことさえ知らずに修正を送信しました。そこにはより深い問題があります：提出者が回帰についてすでに知っていない理由およびなぜ彼らはそれを自分で修正しなかったのですか？説明した状況は、最初の提出者の説明責任または警戒。これは、全体的なパフォーマンスと動機に関して潜在的な懸念です。
私のソフトウェアエンジニアリングの経験により、私が担当するプロジェクトだけでなく、本番環境に至るまでのすべてのコード変更を所有するようになりました。
誰かの変更が問題を引き起こしたとしても、それはその人が悪いエンジニアであることを意味するわけではありませんが、通常は彼らが責任を負い、何が悪いことでも修正する責任があります。それらが「過失」ではない場合でも、例えば彼らのコードは何年もコードベースに存在していた根本的なバグを露呈しました、彼らは彼らの変更に関する問題に気づく最初の人々の一人であるべきです。元の送信者がバグを修正するのに適切な人物ではない場合でも、変更のライフサイクルと密接に関係している必要があります。
あなたの質問に良い牽引力！誰もがあなたに何をすべきかを教えてくれました。教えてください。はい！質問が「もっとコミュニケーションをとるべきですか？」と尋ねるときはいつでも、答えはほとんど常にYESです！
しかし、別のことを追加すると、あなたの前提には欠陥があります。
同僚がCIを壊さないコミットを行いましたが、問題を発見するようにあなたを導きました。
おめでとうございます！回帰ではなく、新しいバグを見つけました。真剣に、コミットするときに、自動（または標準化された手動）テストでカバーされていないすべてのシナリオとコード行を手動でテストしますか？
是非とも、あなたの同僚に修正に関与してもらい、修正が再び起こらないことを確認するテストを行ってください。あなたは両方のヒーローです！しかし、Wordやアクションのせいにしてしまえば、組織の最悪の病気の1つである責任のない責任を永続させる責任があります。
本当にビリアンを見つける必要がある場合は、壊れた元のコードをコミットし、疑いの余地のないバディ（明らかに十分なテストカバレッジがない）の罠を残した男について考えてください。うまくいけば、それはあなたではありませんでした！
他の人が言ったことに加えて、バグの原因が実際に彼らのコミットであることを確認してください。確かに、自分の過ちを他人のせいにしないでください。どんなに巧みに彼らに近づいても、彼らがしなかった何かのために彼らを非難したなら、あなたはまだ彼らを怒らせるでしょう。 （他の人のバグのせいで絶えず責められてきた人物として話す;誰かが私に近づいてきて、私がまったく愚かなことをしたと言ったとき、私はコミットログを持ち出し、そのコード行に最後に触れた人が私を非難していた人。どういうわけか彼は私が最初に行を書いたのでそれは私のせいだとまだ思われていたようです。）
はい。コードに加えた修正を確認するように依頼します。時々私は、他の誰かのバグが実際にはコードのトリッキーな部分であり、バグが単に修正されただけでは他の目に見えない結果をもたらすことを発見しました。
簡単な答え：はい。
より長い答え：私の最後の仕事は、CIツールを備えたTDDを使用して、SVNリポジトリの内容が常に機能し、コードが機能することを確認するアジャイル企業でした。何かがコミットされると、TeamCityサーバーはコピーを取得し、コンパイルして、単体テストを実行しました。また、統合テストを1時間ごとに実行しました。 CIが失敗する原因となった何かがコミットされた場合、特定の人によるコミットに基づいてビルドが壊れたことを知らせる電子メールが全員に届きました。
それは常にすべてをキャッチしたわけではありません。悲惨なことに、コードカバレッジを適用していませんでした。ユニットテストや統合テストで何かがカバーされていたとしても、コードが十分にexerciseでなかった可能性があります。その場合、既知の問題（QAで検出された場合）または欠陥（dun-dun-dunでクライアントで検出された場合）を修正するタスクを取得した人は誰でも「責任」を実行します（誰が最後に各行を変更したかを示します）コードファイル）と原因を特定します。
壊れたコードをチェックインするために誰かを呼び出すことは、必ずしも悪いことではありません。彼らは自分の仕事を適切に行うことができず、彼らまたは他の誰かが戻って間違いを修正しなければなりませんでした。これは常に起こります。それがどれほど大きな問題になるかは、修正がいかに簡単であったか、間違いがその人が問題のコードをコンパイルも実行もしなかったことを示しているかどうか、そして企業文化全体に依存します。全体として重要なのは、間違いを犯した人が何かを学ぶということです。同じ人が原因でビルドが何度も壊れた場合は、その人に対処する必要のあるより深い問題があります。ビルドが常に壊れている場合は、チームのコミュニケーションまたはプロセスの知識に問題があることを示しています。
常に他の人をあなたよりも良い人と見なし、常に他の人の良い特徴を見て、私も間違いを犯すことができることを常に知っています。
二人だけの時は教えて。
あなたが彼に間違いを犯したと言ったときに誰かが気分を害した場合、それは彼が地球上で最も賢いと考え、間違いがないことを意味し、批判されたとき、彼はポーランドで述べたように、「クラウンは彼の頭'。
だから誰かが間違いを犯したと言うのをためらわないでください。正常です。誰もが間違いを犯します。何もしない人だけがミスをしない;）
質問に対するトップ投票のコメントを反映する単一の回答がここに表示されないのはなぜですか？
はい、絶対にそれについて伝えますが、チーム全体の前では行わないでください
開発者に1対1でアプローチし、バグを指摘します。大したことはありません。チーム全体の前でエラーを指摘することは悪い考えだといつも思っていました。一部の開発者には効果があるかもしれませんが、すべての開発者に効果があるわけではなく、悪影響が生じる可能性があります。覚えておいてください、私達はいつかどこかで彼らの立場にありました、そして2番目に投票された答えが言うように、あなたはあなたの過ちから学びます
私は通常、お世辞から始めてエラーに到達したときに最もうまくいくと思います...「実装した修正はうまく機能しますが、x、y、zが壊れているようです」、「 、b、c、しかしそれはx、y、zを引き起こしているようです
多くの要素が関係しています。
- バグはどのくらい深刻ですか？
- あなたとブレーカーの間の年功関係は何ですか？
- チームはどのくらい忙しい/ストレスがたまっていますか？
- ブレーカーはコードベースの一部で機能していましたか？
- それが本当のバグであるという確信はどれくらいありますか、そしてあなたの修正が正しいという確信はどれくらいありますか？
問題が軽微である-typo/thinko/cut＆pasteバグ-ブレーカーが忙しいピアであり、問題の評価に自信がある場合は、おそらく彼らに注意を喚起する必要はありません。 （例：foo.x = bar.x; foo.y = bar.y, foo.z = bar.y）。
他のほとんどの場合、問題について言及することをお勧めします。深刻でないケースでは、彼らがしていることを中断する必要はありません。昼食をとるか、休憩室でぶつかったら待ってください。
ただし、エラーの性質が（実装プラットフォーム、ローカルポリシー、またはプロジェクト仕様の）重大な誤解を示している場合は、できるだけ早く報告してください。
評価が不確かな場合は、修正に目を通すように依頼してください。特に、よく知っているコードに含まれていない場合は修正を検討してください。 （とにかく、あなたの開発チームは、すべての変更がチェックインの前に他の1人によってレビューされる「コードバディ」ポリシーを採用することを強くお勧めします。）
伝えないとどうなりますか？
短所
彼らが問題を引き起こしていることを理解していないので、彼らは他の場所で同じ間違いをするかもしれません。それだけでなく、同じ間違いを繰り返し修正するために余分な不要な時間が発生します。あなたは自分がネイドしていることに気づいていない間違いから学ぶことはできません。
第二に、彼らは自分たちよりも良い仕事をしていると思っています。人々が自分たちの問題に気づかされていないとき、彼らがそうでないときに彼らがうまくやっていると考えていることで彼らはほとんど非難されることができません。問題が不注意な間違いであっても、気づかされていることに気づいている人は少なくなります。
次に、誰かが誰がそれを行ったのか調べない場合、常に不注意であるか、製品の基本的な誤解を抱えている特定の問題のある従業員がいるかどうか、どうすればわかりますか？責任者は、自分が関連付けられているチームで続行することを望みますか？
あなたがそれを議論せずに修正して次に進むならば、あなたは確かにそれを正しく修正しましたか？要件が変わったときに変更が必要なのは、テストです。それがかなりマイナーなタイプミス以外のものである場合、どちらかが正しい解決策を持っていることを本当に確信できますか？相談せずに見返りに彼のコードを壊すかもしれません。
長所
人々は彼らの過ちを指摘するためにあなたに恥ずかしいや悩まされません。
私は彼らに話す側に強く降りてくると思いますが、それを上手にそして個人的に行います。公の屈辱の必要はありません。その人が繰り返し同じ間違いをしたり、理解の欠如を示す重大な間違いを犯したりしている場合は、監督者も同様に認識させる必要があります。