コードレビューの速度
なぜコードレビューを迅速に行うべきか
Googleでは、開発者チームが一緒に製品を生産する速度を最適化します。これは、個々の開発者がコードを書く速度を最適化することとは対照的です。個々の開発速度も重要ですが、チーム全体の速度ほどではありません。
コードレビューが遅いと、いくつかの問題が生じます：
- チーム全体の速度が低下します。 レビューにすぐに対応しない個人は他の仕事を進めるかもしれません。しかし、チームの残りの部分にとっての新機能やバグ修正は、各CLがレビューと再レビューを待つ間、日、週、または月単位で遅れます。
- 開発者がコードレビュープロセスに抗議し始めます。 リビューアが数日おきにしか反応せず、その都度CLに大きな変更を要求する場合、それは開発者にとってイライラすることであり、困難です。しばしば、これは「リビューアが厳しすぎる」という不満として表現されます。リビューアが開発者が更新を行うたびに_迅速に_同じ重要な変更（実際にコードの健全性を向上させる変更）を要求する場合、不満は消える傾向があります。コードレビュープロセスに関するほとんどの不満は、プロセスを迅速にすることで実際に解決されます。
- コードの健全性に影響を与える可能性があります。 レビューが遅いと、開発者がそれほど良くないCLを提出する圧力が増します。遅いレビューは、コードのクリーンアップ、リファクタリング、および既存のCLへのさらなる改善を抑制する傾向があります。
コードレビューはどれくらいの速さであるべきか
集中しているタスクの最中でない限り、コードレビューは受け取った直後に行うべきです。
コードレビュー要求に対して反応する最大時間は1営業日です（つまり、翌朝の最初の時間）。
これらのガイドラインに従うと、典型的なCLは必要に応じて1日以内に複数ラウンドのレビューを受けることになります。
速度 vs. 中断
個人の作業速度がチームの速度を上回るべき唯一の時があります。コードを書くなど、集中している作業の最中に、自分を中断してコードレビューを行うべきではありません。 研究によると、中断された後に開発のスムーズな流れに戻るまでには、開発者に長い時間がかかることが示されています。従って、コーディング中に自分自身を中断することは、他の開発者がコードレビューを少し待たされることよりも、実際にはチームにとって_より_コストがかかることになります。
代わりに、作業の中断点でレビューの依頼に応答することを待ちます。これは、現在のコーディングタスクが完了した時、ランチ後、会議から戻った時、休憩室から戻ってきた時などが該当します。
迅速な対応
コードレビューの速度について話す際、私たちが関心を持っているのは、CLがレビューを通過して提出されるまでにかかる時間ではなく、_対応_の時間です。全プロセスも理想的には速いべきですが、個々の対応が迅速に行われることの方が、全プロセスが迅速に行われることよりもさらに重要です。
たとえ全体のレビュー_プロセス_を通過するのに時々長い時間がかかる場合でも、プロセス全体を通じてリビューアからの迅速な対応があることで、「遅い」と感じる開発者のフラストレーションが大幅に軽減されます。
CLが到着した時に完全なレビューを行うのにあまりにも忙しい場合でも、いつ対応できるか開発者に知らせる迅速な返答を送ったり、より迅速に対応できる可能性のある他のリビューアを提案したり、いくつかの初期の広範なコメントを提供することができます。（注意：これは、このような返答を送るためにさえコーディングを中断すべきだという意味ではありません。作業の合理的な中断点で返答を送ってください。）
リビューアがレビューに十分な時間を費やし、「LGTM」が「このコードは私たちの基準を満たしている」ということを確信していることが重要です。 しかし、個々の対応は理想的には迅速であるべきです。
時差を考慮したレビュー
時差の差を扱う際は、彼らがその日の業務時間内に返答できるように、著者に返答しようと努めてください。彼らがすでにその日の業務を終えていた場合は、彼らが翌日の業務を開始する前にレビューを完了させるようにしてください。
コメント付きLGTM
コードレビューを迅速に進めるため、リビューアが未解決のコメントを残しつつもLGTM/承認を出すべき特定の状況があります。これは以下のいずれかの場合に行われます：
- リビューアが開発者が全ての残りのコメントを適切に対処すると確信している場合。
- 残りの変更が些細で、開発者が必ずしも行う必要はない場合。
リビューアは、どちらのオプションを意図しているかを明確に指定すべきです（それが明確でない場合）。
開発者とリビューアが異なるタイムゾーンにいて、開発者が「LGTM、承認」を得るために1日待たなければならない場合には、特にコメント付きLGTMを検討する価値があります。
大きなCL
あなたにとても大きなコードレビューが送られてきて、いつレビューできるか分からない場合、通常の対応は開発者にCLをいくつかの小さなCLに分割するよう依頼することです。これは、開発者に追加の作業が必要であっても、通常は可能であり、リビューアにとって非常に役立ちます。
CLを小さなCLに分割_できない_場合、そしてあなたがすぐに全体をレビューする時間がない場合は、少なくともCLの全体的な設計についていくつかのコメントを書き、改善のために開発者に返送してください。リビューアとしてのあなたの目標の1つは、コードの健全性を犠牲にすることなく、常に開発者のブロックを解除するか、迅速に何らかの行動を取ることができるようにすることです。
時間と共に改善されるコードレビュー
これらのガイドラインに従い、コードレビューに厳格であれば、コードレビュープロセス全体が時間とともにますます速くなることがわかるでしょう。開発者は健全なコードに必要なことを学び、最初から素晴らしいCLを送ってくるようになり、レビュー時間がますます少なくなります。リビューアは迅速に対応し、レビュープロセスに不必要な遅延を加えないように学びます。 しかし、速度の想像される改善のためにコードレビュー基準や品質を妥協しないでください—それは実際には何も早く進めることはありません、長い目で見れば。
緊急事態
CLが非常に迅速に_全_レビュープロセスを通過しなければならない緊急事態もあり、その場合は品質ガイドラインが緩和されるかもしれません。しかし、どの状況が実際に緊急事態として資格があるか、そしてどれがそうでないかについての説明は、何が緊急事態か？をご覧ください。