他の開発者を害することなくコードレビューを行う方法

Question

私は頻繁にコードレビューを行うチームで働いています。しかし、それは何よりも形式的なもののようです。

他の開発者の気分を害するのを恐れて、コードの問題を指摘する人はいません。私が変更を要求しようとした数回は、非常に防御的で消極的な態度に遭遇しました。

これはもちろん良くありません。コードレビューに時間を費やすだけでなく、文字通りゼロの価値を得ています。これは、個々の開発者が対処する必要のある問題ですか、それとも他の人の足を踏まずに変更を提案するための手法はありますか？

Joel Etherton · Accepted Answer

これは、一部の開発者の間ではかなり一般的な態度のようです。誰もがコードレビューは彼らの仕事に対するいくつかの挑戦であると感じているようで、それは私には意味がありません。コードレビューは品質保証メカニズムであり、それに伴って教育のボーナスが追加されます。私たちはコードレビューを私が働いている場所で広範囲に実装しており、コードレビューは品質プロセスよりもコラボレーションメカニズムであるという態度を自分のチーム内で育んでいます。

teamとしてコーディングを開始する唯一の方法は、お互いの作業を確認して質問することです。これがベストプラクティスの形成方法です。ダイアログが鍵です。書式設定、ベストプラクティスの合意、スペルなど、ばかげた理由でコードを開発者に送り返しました。私は非常に細かいEdgeを使用してコードレビューを行っており、自分のコードが同じ精査に耐えることを期待しています。私は、ジュニア開発者にchallenge meを依頼することのみを目的として、自分のコードレビューに合格しないコードをチェックインするなどの戦術を使用しました。要件を満たしていないことを教えてください。立ち上がって意見を述べる。

コードレビュー環境に携わるときに誰もが本当に持つべきいくつかのガイドライン：

自分を乗り越えます。あなたは完璧ではありません。そして、ジュニア開発者があなたがforループでばかげたことをやったと思ったからといって、世界の終わりではありません。あなたがとても素晴らしいなら、批判を招いてそれを証明してください。物事を行う方法、新しい習慣、そして何よりも建設的な対話についての新しいアイデアを明らかにするために、コードレビューを期待してください。
他人のコードをレビューするときは、心を開いてください。彼らの考えを受け入れ、あなたが提案する変更が理由のために提案されていることを確認してください。チェックインされたコードがビルドされることを前提としていますが、それがベストプラクティスに従っていることを意味するものではありません。取り上げたものはすべて引用文献でバックアップできることを確認してください。ベストプラクティスに従っていないという場合は、標準のドキュメントとセクションを引用してください。「パフォーマンスの高い」方法ではないと言う場合は、理由を示し、場合によっては指標を提供するドキュメントへのリンクを用意してください。
提案を有用にし、何か提案している理由を説明します。あなたはたまに自明のコードで問題を見つけるでしょうが、ほとんどの場合、この人は習慣に基づいて何かをコーディングしました。この習慣を変える必要がある理由とそれを変えることの価値を説明してください（人事上の問題がある5回目の説明でない限り）。
コードをレビューするときは、レビュー担当者が客観的に提案していることをすべて考慮してください。反発している場合は、防御しているだけなのか、それともあなたが事件があると本当に信じているのか、正直に自問してください。ケースがある場合は、ダイアログを続行してください。議論の余地はなく、事実や測定基準などの弾薬を持参してください。
レビュアーでもレビュイーでも、コードレビューを教育の機会として使用してください。それが自分自身を教育しているのか、レビューしている人を教育しているのかに関わらず、矛盾があれば、どこかで学ぶ機会があります。それをうまく活用してください。
質問をし、あなたの質問が正直に答えられるように準備してください。私は最近「疑似真実」であると述べました。間違いではありませんでしたが、間違いでした。ジュニア開発者が私にそれに挑戦し、私は反対しました。私の返事は「私はその振る舞いを見たことがありませんが、それについての文書が見つかれば私はそれを読んでみたいです。」でした。私は午後に彼が私に送った文書を読むのに約1時間費やしましたが、今では同様の状況に直面したときの方がはるかに良い応答（再教育）を得ることができました。

私がコードレビューを入れた教育の傾斜を考えると、私はしばしば質問について私の返答をします。私が露骨にぎこちないものを見つけた場合は、それを修正するように開発者に指示します。それ以外の場合は質問します。「なぜ方法Aを使用して目標Bを達成したのですか？」「変数を宣言することは、メソッドZでの使用法のインスタンスにどのような利点がありますか？」「一部のコードをコピー/貼り付けたようですが、リファクタリングを検討しましたか？リファクタリングしませんでした。その選択の理由は何ですか？」コードはレビュー担当者が承認するまで進行せず、レビュー担当者は質問に回答するまで承認しません。好奇心旺盛な方法でフレームを作成すると、開発者が理解を理解できないため、対立が少なくなり、教育的な雰囲気が高まります。

DHall · Answer

人々が個人的にコードレビューを行う手助けをするために、批評や提案をその作者ではなくコード自体に向けるようにしてください。例えば、

関数「getFoo」はxyzを実行する必要があります。

よりも良い

関数「getFoo」でxyzを実行する必要があるのは...

一方、肯定的な意見を表明したい場合は、著者を称賛することができます。例えば、

私はあなたがabcアルゴリズムをどのように使用したかが好きです...

meriton · Answer

最初に、チームはコードレビューの目的に同意する必要があります（コードレビューはさまざまな目的で使用でき、組織ごとに理由が異なるため、このような同意を当然のこととして受け取らないでください。この回答では、目標が開発者の将来の仕事を改善することであると仮定します。

改善するには、開発者は知る必要があります

何が良かった？ ->私はそれを続けなければなりません
何が悪かった？ ->変更する必要があります
なぜ？ ->そのため、問題の重大度を評価し、将来同様の問題を認識することができます

これはどのようなアクションですか？

フィードバックは人ではなく、行動に関するものでなければなりません。したがって、フィードバックの動作を（できれば例とともに）識別する必要があります。だから言ってはいけない：

あなたは怠惰です。

それは振る舞いではなく、（知覚された）人格に関するものだからです。また、あいまいすぎます。これは、長い昼休みについてですか？タイピングが遅い？タイムリーにメールに返答しませんか？実装されている機能が少なすぎますか？代わりに、次のように言う必要があります。

先週、バグ＃1059が割り当てられました。この欠陥を解決済みとしてマークしましたが、バグはまだ存在しており、トラブルチケットに記載されている手順で再現できます。

そしてなぜ？

次に、そのアクションまたはコードが良かった理由を説明する必要があります。与えられた理由は客観的で、変更を正当化するのに十分重要なものでなければなりません。例えば：

AClass.amethod（）は並行スレッドによって呼び出されますが、スレッドセーフではありません。データが破損している可能性があります。

または

このメソッド名は誤解を招く可能性があります。給与等級を計算するだけのように聞こえますが、実際には従業員にも給与を支払っています。実装に慣れていない誰かがメソッドを誤用し、偶発的な給与支払いを引き起こす可能性があります...

もちろん、なぜコードが悪い（または良い）かという根拠のない議論がない場合もあります。これは、自分が正しいことを知らないことを意味します。したがって、推定ではなく、好奇心旺盛な方が賢明です。

これはひどく複雑に見えます。代わりにAClass.amethod（）を呼び出さないのはなぜですか？

または

これは、AClass.amethod（）とほぼ同じように見えます。その方法を再利用できないのはなぜですか？

もちろん、肯定的なフィードバックを与えることもできます。

これは、ワーカースレッドを調整するための優れたアプローチです。通常は代わりにXを使用しますが、どうしたらそれをより堅牢にすることができるのかといつも疑問に思いました。今私は知っている：-）

これを行わないでください

上記の重要性を説明するために、正式なコードレビューから逐語的に取られた実際のカウンターの例を考えてみましょう：

コードは、よく考えられていない印象を残します。

そして、それは査読者がその発見について書いたすべてです。

それは非常に多くのレベルでのひどいフィードバックです：

フィードバックは、著者について気の遠くなるようなものを意味します（つまり、彼はよく考えていません）
フィードバックは印象に関するものです。それは客観的ではありません。
フィードバックは、変更が必要なコードの部分を特定していません。
それがあるべき理由も与えないでください。

そのような「フィードバック」の受信者は、自分が何を変更する必要があるのか、またその理由を知ることができず、したがって何も学ぶことができません。実際、彼はフィードバックが公平であることを知ることすらできず、根拠のない根拠のない結論を考えると、これを仲間を押し下げることによって自分自身を昇格させようとする誰かによる個人攻撃と見なす可能性がはるかに高くなります。叫びが続く可能性があります。

ratchet freak · Answer

コードレビューは、不合格/合格だけではなく、失敗した場合にのみ詳細なフィードバックを返す必要があります。これはネガティブに焦点を合わせる傾向があり、人々を批判にさらすことをやめさせます。

レビューアーは、「私が自分の仕事をしていて、自分の机に出くわすすべてを批判しているように見える」という観点から、マネージャーの目にもっと脚光を浴びるために、より否定的な反応を示すかもしれません。

提出者に返されるコメントフィールドを追加すると、失敗または合格すると、彼は自分の作業に対してより前向きになり、レビュー担当者は、コードがレビューに合格した場合でも、改善すべき点についてフィードバックを提供できます。これにより、レビュアーは、コードに限定されたリファクタリング（フォーマット、変数名の変更）を行うことができます。

gbjbaanb · Answer

彼らは「コードはチームによって所有されるべきである」と言っているので、レビューは個々のコーダーに対する個人的な攻撃ではなく、チームの他のメンバーが物事を理解できるようにするための質の高いステップです。私が働いたほとんどの場所だと思いますが、これは理解され受け入れられています。

しかし、他の人のコードをレビューするという考えに反対していたため、候補者として彼を拒否した男にインタビューを行いました！（つまり、彼のコードをレビューしてもらったのではなく、レビューを行っている...奇妙でした）。

そのため、レビューへの取り組み方の問題について少し考えさせられました。コードレビューを行うより良い方法は、私の回答の最初の行を覚えて、それを基にすることです。これを行うのは非常に簡単です。コードレビューは、「誰かが私のコードをチェックアウトして、私が間違ったことを教えてくれる」という認識をやめ、コーダーが他の人に自分のコードが何をしているかを伝える機会になります。、および彼らが行った変更。

この場合、コーダーは自分のコードをレビューすることになり、見落としている可能性のあるビットを見つけるのに役立つ目が追加されます。また、コーダーがなぜ彼が特定の方法で物事を行ったかを説明する機会でもあります。このようなアプローチは同じくらい効果的であり（コミュニケーションをうまく交換できるほどではないにしても）、かなり友好的です。元のコーダーが変更を直接説明できるため、レビューがより迅速になるはずであることを考えると、それほど時間がかかるとは思いません。人々はまた、将来コードを保守する必要があるかもしれない別のチームメンバーに知識を「引き渡す」ときに、そのようなレビューの必要性を理解する必要があります。

「レビュアー」に変更の元の要件を用意してもらい、解決策が詳細になっていることをチェックして、コードレビューのように感じることを減らすことで、これを強化できます。