少し前まで、私の同僚はコードレビューに関する興味深い記事を翻訳していたので、翻訳が気に入りました。 そして今朝、紛らわしい相互参照グラフにより、 eyeofhellはさらにクールな記事になりました。 他の人のコードをレビューし、自分のレビューを生き抜く方法に関する簡潔で簡潔な指示を翻訳するように注意を促します。 上記の記事とは異なり、この記事ではコードレビューの実用的な側面に重点を置き、耐え難いほど苦痛にならないように、どのように、何をすべきかに関する多くの有用な推奨事項を紹介します。 ヒント：オリジナルを読むには、翻訳の下のプレートで著者の名前をクリックしてください。
すべての参加者のコードレビュー
- 多くのアーキテクチャ上の決定は、開発者の個人的な好みの問題であることを当然と考えてください。 長所/短所のみを話し合い、できるだけ早くコードをどうするかを決めてください。
- 要求しないで、質問してください。 例：「識別子名user_idの使用についてどう思いますか？」。 翻訳者のメモ：このアドバイスは、人間の脳は批判や要求に対して強い感情的な反応を引き起こす傾向があるという観察に基づいていますが、議論への招待はしばしば感情的な要素を通り過ぎて、コードについて冷静に話すことができます。
- 曖昧な点を明確にしてください。 例：「ここで何が起きているのかわかりません。 もう少し説明してもらえますか？」
- コードをyours / alienに分割しないようにしてください。 「私のもの」、「私のものではない」、「あなたのもの」という言葉に疑いを持つ。
- プログラマーではなく、プログラムについて話し合ってください。 パーソナリティへの切り替えを避け、「愚かな決定」や「馬鹿げたコード」などの表現を使用しないでください。 チームメンバー全員がそうであるように、コードレビューを実施します。
- 自分の考えを明確に表現してみてください。 人々は常にあなたの意図をオンラインで理解する方法ではありません。
- 例えば、「これが機能するかどうかわかりません。確認しましょうか？」
- 「常に」、「決して」、「何もない」などの言葉を誇張し、可能であれば避けてください。
- 皮肉も良いことではありません。
- このフレーズがどんなにフレーズされていても、自分らしくなってください。 絵文字、アニメーションGIF、およびユーモアが「あなたのものではない」場合、他のチームメンバーのようになろうとして、自分を無理にしないでください。
- ディスカッションに「理解できませんでした」および「この問題を解決する別の方法がある」というメモが多すぎる場合は、このコードを直接話し合ってから、コードレビューの一環として短いフォローアップを書くことをお勧めします。
コードがコードレビューを受けた場合
- 完了した作業についてレビュー担当者に感謝することをお勧めします。たとえば、「この興味深い状況を見つけたおかげで、作業を完了するためのロジックを変更します。」
- コードレビューの結果を心に留めないようにしてください。 あなたではなくコードについて話し合ってください。
- 問題のある状況では、このコードが書かれた理由を説明してください。 「なぜ」という質問に対する答えは、コミュニケーションを簡素化します。
- すべてを1か所にまとめるのではなく、膨大な修正を別々のタスクに入れることをお勧めします。
- 対応するタスクからコードレビューへのリンクを作成します。たとえば、「完了、確認できます： github.com/organization/project/pull/1 」。
- レビューが完了するまで、スカッシュを連結しないでください。 レビュー担当者には、個々のコードの問題を修正する個々のコミットを確認する機会があります。
- 校閲者の視点を理解するようにしてください。
- すべてのコメントに返信することをお勧めします。
- すべての継続的な統合テストに合格するまで、マージを行う必要はありません。
- Mergeは、コードとプロジェクトへの影響に自信がある場合にのみお勧めします。
他の人のコードレビューをレビューする場合
まず、このコードが書かれた理由を理解してください。 これはバグ修正ですか？ 新機能？ リファクタリング？ 上記のすべての血まみれの混乱？ 次に：
- どのコメントであなたが完全に確信しているのか、そしてどのコメントであなたがあまり確信がないのかを明示的に示すようにしてください。
- 機能を失うことなくコードを簡素化する方法を教えてください。
- コードの議論が哲学的または学術的なジャングルになった場合、そのような議論はオフラインにするのに適しています。 たとえば、伝統的な金曜日の集まり。 あなたのチームは金曜日に集まりますか？
- 代替ソリューションを提案しますが、作成者がすでにそれらを試しているという仮定から進めます。 例：「カスタムバリデーターについてどう思いますか？」
- コードの作成者の視点を理解するようにしてください。
- コードレビューの最後に、プルリクエストに「マージできます」というコメントを付けます。
コード設計の考慮事項
コードがチームによって採用されたエンコードスタイルに明示的に違反していることがわかった場合は、コードレビュー中にこれを示すと便利です。 チームの誰かがこのスタイルに同意しないことが判明した場合は、別のチケットでディスカッションを送信することをお勧めします。