Google コードレビュー開発者ガイド
有志の方が翻訳してくださった Google のエンジニア開発者ガイド 感想
コードレビューの基準
レビュワーは CL の品質を確認する義務がある
多くの場合、コードの健康状態を悪化させる要因が積み重なり、コードベースの品質は徐々に下がります。 特に、チームが無視できない時間的制約に縛られていて、ゴールを達成するためにはショートカットをするしかないと感じているときには、コードベースの品質は下がりやすいものです。
最上位の原則
一般に、CL が完璧でなくても、その変更がシステムのコードの全体的な健康状態を改善すると確実にわかれば、レビュアーは CL を積極的に承認すべきである。
コードレビューの観点
コードがうまく設計されている
機能性がコードのユーザーにとって適切である
UI の変更がある場合、よく考えられていて見た目も適切である
並行処理がある場合、安全に行われている
コードが必要以上に複雑でない
開発者は将来必要になるかもしれないものではなく、現在必要だとわかっているものを実装している
コードには適切なユニットテストがある
テストがうまく設計されている
開発者はあらゆるものに明確な名前を使った
コメントは明確で有意義なもので、「何」ではなく「なぜ」を説明している
コードは適切にドキュメント化されている(一般的には g3doc で)
コードはスタイルガイドに準拠している
レビューを依頼されたコードを一行ずつレビューすること、コンテキストを確認すること、コードの健康状態を改善しているかを見極めること、開発者が良いことをしたらそれを褒めることを忘れずに。
コードレビューのスピード
あるタスクに集中的に取り組んでいる最中でなければ、コードレビューの依頼が来たらすぐに着手してください。
最長で1営業日
レビューコメントの書き方
コメントは丁重に
理由を説明してください
問題の指摘に加えて明確な方向性を示すことと、開発者本人に決定を委ねることをバランス良く行ってください
複雑なコードを見つけたらそれを説明してもらうだけで終わらせず、コードをシンプルにしてもらうとかコードにコメントを追加するよう開発者に勧めてください