コードレビューのスピード
なぜコードレビューは素早く行うべきか？
Google では開発者のチームが協力してプロダクトを高速に開発するために最適化しており、開発者個人がコードを高速に書くための最適化はしません。 開発者個人のスピードは確かに重要ですが、チーム全体のスピードと比べると同等の重要性があるわけではありません。
コードレビューが遅滞するとさまざまなことが起こります。
- チーム全体の開発速度が減少します。もちろん、レビューに素早く反応しなくても個人としては他の仕事を終わらせられます。 けれども、チームの他のメンバーが書いた新機能や不具合修正は、CL がレビュー待ち、再レビュー待ちになると何日も何週間も遅れることになります。
- 開発者がコードレビューのプロセスに不満を持ち始めます。 レビュアーが数日おきにしか返信しないのに毎回 CL への大きな変更が要求されると、開発者はストレスをためるし開発が困難になります。 よくあることですが、このようなときに表現される不満は、レビュアーが「厳しすぎる」というものです。 本質的には同じ変更（実際にコードの健康状態を良くする変更）でも開発者の更新に応じてレビュアーが毎回素早く返信すれば、このような不満は薄れます。 コードレビューに関する不満はたいていの場合、プロセスをテンポ良く進めるだけで解消します。
- コードの健康状態が悪い影響を受けます。 レビューが遅いと、最高の出来映えといえないような CL でもとにかく提出してしまってよいという雰囲気が開発者の間に広がります。 また、レビューの遅れはコードをきれいにしたり、リファクタリングしたり、既存の CL をさらに改善したりする意欲をそぎます。
コードレビューはどれほど急ぐべきか？
あるタスクに集中的に取り組んでいる最中でなければ、コードレビューの依頼が来たらすぐに着手してください。
コードレビューのリクエストに返信するまでの最長の時間は一営業日です（つまり遅くとも翌朝一番に返信すべきです）。
このガイドラインに従うと、典型的な CL は（必要なら）一日以内に複数ラウンドに渡ってレビューが行われることになります。
スピード vs 割り込み
チームの速度よりも個人の速度を尊重したほうが効率が良い場合があります。 コードを書くような集中的に取り組むべきタスクの最中には、自分のタスクを中断してコードレビューしてはいけません。研究結果によれば、開発者が割り込み作業のあとでスムーズな開発フローに戻るには長い時間がかかることがあります。 そのため、コーディングの最中に中断すると、他の開発者がコードレビューを多少待つよりも結果的に余計なコストがかかります。
それよりは仕事のブレークポイントを待ってからレビューのリクエストに返信しましょう。 たとえば今のコーディングが完了したときや、ランチの後や、ミーティングから帰ったとき、マイクロキッチンから戻ったときなどです。
素早い応答
コードレビューのスピードについて話すとき、私達の関心は応答時間の長さであり、レビュー全体が完了して提出されるまでの時間の長さではありません。 理想的にはプロセス全体も短時間で行うべきですが、** 個々の応答 を素早く行うことのほうが、プロセス全体を短時間で終えることよりも遥かに重要です。**
たとえレビュー全体のプロセスに長い時間がかかってもレビュアーから素早く応答がもらえていれば、開発者が「遅い」コードレビューに感じる不満を大きく軽減できます。
あなたが非常に忙しくて CL のレビュー依頼をされても十分な時間が取れない場合、それでも素早く応答することはできます。いつ着手できるかを開発者に伝えたり、もっと短時間で応答できる他のレビュアーを紹介したり、広い観点で見た初期段階のコメントを残したりできます。（注：そういった返信をするとしてもコーディングを中断するべきではありません。仕事中にちょうどいいブレークポイントを見つけて返信してください。）
レビュアーが十分な時間を取って、「LGTM」が個人の感想でなく「このコードは私達の基準を満たしている」という意味だと言えるくらいにレビューするのは大切なことです。同時に、理想的には個々の応答は素早く返信すべきです。
タイムゾーンをまたがるレビュー
タイムゾーンの違いを取り回すには、CL 作成者がいつオフィスに確実にいるかを確認するようにしてください。すでに家に帰ってしまったかもしれません。そのときには翌日に作成者がオフィスに戻る前にレビューを完了するように心がけてください。
コメント付きの LGTM
コードレビューのスピードを上げるために、レビュアーが CL に未解決のコメントを残しつつも LGTM / 承認を与えるというケースがあります。これは次のいずれかに当てはまる場合にそうするべきです。
- 開発者がレビュアーの残したコメントに後で着実に取り組んでくれるとレビュアーが信頼できるとき
- 先送りにした変更がさほど重要でなく、開発者本人が必ずしも行う必要のないとき
これらのうちどちらがレビュアーの意図なのかをはっきりさせておかないと、曖昧な態度は開発者を混乱させます。
コメント付きの LGTM が価値を発揮するのは、特に開発者とレビュアーが別々のタイムゾーンで仕事をしているときです。このやり方でレビューを進めないと、開発者は「LGTM / 承認」をもらうためだけに丸一日待たなければならなくなります。
大きな CL
送られてきたコードレビューがあまりに巨大で、じっくりレビューする時間を取れるか不安なときには、開発者にその CL を小さな CL に分割するよう依頼するのがよくある対応策です。 一度にレビューするのが大変な一つの巨大な CL ではなく、それぞれが関連している小さな CL に分割するのです。 これは開発者にとってみれば仕事が増えますが、普通の CL では不可能な作業でもなく、レビュアーにとっては非常に助かります。
CL が小さな CL に分割できない場合、またさらにレビュアーがすぐにコード全体をレビューする時間が取れないとき、それでも少なくとも CL の全体的な設計に関してコメントを書き送り、開発者に改善を求めることができます。 いつでも言えることですが、レビュアーとしてのゴールの一つは開発者を作業を滞らせないこと、あるいは次のアクションをすぐに起こせる状態にしておくことです。もちろんコードの健康状態を犠牲にしてはいけませんが。
コードレビューを長期的に改善する
あなたがこのガイドラインに準拠してコードレビューを厳密に行っていけば、全体的なコードレビューのプロセスが時間をかけてだんだんと速くなっていくのがわかるはずです。 開発者は健康的なコードを書くために何が必要かを学び、最初から質の高い CL を送るようになり、レビューに必要な時間はだんだんと減っていきます。 レビュアーは素早く応答することを学び、レビュープロセスに無駄な遅延がなくなります。 それでも、コードレビューの基準に妥協しないでください。スピードを上げてもコードの品質の改善に妥協しないでください。長期的にみれば、レビューが短時間で終えられたからといって、それだけでひとかどの仕事をしたことにはなりませんから。
緊急事態
緊急事態というものもあります。緊急事態の CL は全レビュープロセスを素早く終えなければなりませんし、品質に関するガイドラインは緩められます。 けれども、どんな状況が緊急事態に該当するのか、逆にどんな状況が緊急事態に該当しないのかを判断するために何が緊急事態か？を確認してください。