コードレビューのスピード
なぜコードレビューは早くなければならないのか？
Google では、開発者のチームが1つの製品を協力して開発する速度を最適化しています。これは、個人の開発者がコードを書くことができる速度を最適化するのとは逆です。個人の開発者の速度が重要なのは確かですが、チーム全体の速度と同じくらい重要というわけではありません。
もしもコードレビューが遅かった場合、以下のような問題が起こってしまいます。
- チーム全体の速度が低下してしまう。たしかに、ある個人がレビューに速やかに返事をしなかったとしても、他の仕事を進めることはできます。しかし、各 CL のレビューや再レビューの遅れが積み重なれば、チームの残りのメンバーが行う新しい機能やバグの修正に、数日、数週間、数ヶ月の遅れが生じてしまいます。
- 開発者がコードレビューのプロセスに抵抗するようになってしまう。もしもレビュアが数日に1回しか返事をせず、CL を送るたびに大きな変更を要求するようなことをすれば、開発者には大きなストレスがかかり、変更を加えるのが大変になってしまいます。多くの場合、このような状況は、レビュアの仕事が「厳しすぎる」という不満として現れます。レビュアが同一の大きな変更を要求したしても、開発者が変更をするたびにすみやかに返事が返ってくれば、不満は無くなる傾向があります。コードレビューのプロセスに関する不満の大部分は、実際にはレビューのプロセスをすみやかに行うことによって解消されます。
- コードの健康状態に大きな影響を与えてしまう。レビューが遅いと、開発者に完璧ではない CL を提出しないようにさせる圧力が掛かります。さらに、レビューが遅いと、コードのクリーンアップ、リファクタリング、既存の CL に対する追加の改善をしようとする気持ちも弱めてしまいます。
コードレビューはどのくらい速く行うべきか？
集中状態にあるタスクがない場合には、レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません。
コードレビューリクエストに対して、返事をするまでに掛けることが許される最大の時間は、1営業日です。 (つまり、最低でも翌日最初にするべきです。)
以下のガイドラインに従うならば、通常の CL では、1日の間に (必要があれば) 複数回のラウンドでレビューを行わなければならない、ということになります。
速さ vs. 中断
個人の速度がチームの速度に優先されると考えられる場合が1つあります。もしあなたがコードを書くなど、1つのタスクに対して集中状態にある場合には、コードレビューをするために自分の集中を妨げてはなりません。これまでの研究によれば、開発者が作業を中断された後に開発のなめらかなフローに戻るためには、長い時間がかかることが示されてきました。そのため、コードレビューをするまでに他の開発者を少しだけ待たせるより、コーディング中に自分の集中を妨げた方が、実際にはより高いコストがかかってしまいます。
その代わり、レビューのリクエストに返事をする前に、自分の仕事に一休みできるタイミングが来るのを待ちましょう。こうしたタイミングとしては、現在のコーディングのタスクが完了した時、ランチが終わった後、ミーティングから帰ってきた時、microkitchen から帰ってきた時などがあります。
素早い応答
私たちがコードレビューの速さについて話すときに関心があるのは、CL のレビュー全体にかかった時間や、CL を提出するまでに掛かった時間ではなく、レビューのレスポンスの速さです。プロセス全体の時間が早いのも理想ではありますが、さらに重要なのは、プロセス全体が高速に行われることよりも、「一つひとつのレスポンス」がもっと早くなることです。
レビューのプロセス全体には長い時間がかかることがあったとしても、レビューのプロセス全体を通してレビュアから素早くレスポンスが返ってくるだけで、開発者がコードレビューが「遅い」と感じることによる苛立ちを大幅に和らげることができます。
もしあなたが忙しすぎて、CL が送られてきてすぐに全体をレビューできない場合でも、素早い返事を送ることで、開発者にいつレビューに取り掛かれるかを伝えたり、もっと早くレスポンスを返すことができる他のレビュアを提案したり、あるいは、いくつか最初の全般的なコメントを送ることができます。(注意: これらのいずれも、こうしたコメントを送るために、あなたが集中してコーディングしているのを中断してもよい、という意味ではありません。作業に集中している場合には、その作業がひとやすみできる適切なタイミングを見つけて返事を送るようにしてください。)
レビュアが「LGTM」という言葉を使う時、本当に「このコードは Google のコードレビューの基準を満たしている」という意味になっているか、レビューに十分な時間をかけて確認することが重要です。しかし理想的には、一つひとつの返信は、やはり速くあるべきです。
タイムゾーンを越えるレビュー
タイムゾーンの違いに対処するために、CL の作者がまだオフィスにいる間に返信を送るように努めてください。すでに自宅に帰ってしまったときは、翌日にオフィスに戻ってくる前にレビューが確実に完了するように努めてください。
コメント付き LGTM
コードレビューのスピードを上げるために、次のいずれかの状況では、CL に未解決のコメントが残っている場合であっても、レビュアが LGTM や承認を与えることがあります。
- 開発者がレビュアに残されたすべてのコメントに適切に対処するであろうことを、レビュアが確信している場合。
- 残された変更が細かいものであり、開発者が必ず変更しなければならないものではない場合。
レビュアがこれらの選択肢のどちらを意図しているのかが明らかではない場合には、明示的にどちらであるかを示さなければなりません。
このような「コメント付き LGTM」は、特に開発者とレビュアが別のタイムゾーンにいる場合に活用を検討する価値があります。これを使わなければ、「LGTM、承認します。」という返事を受け取るためだけに、開発者がまる1日待たされることになりかねないからです。
大きな CL
もし誰かがあなたにとても大きなコードレビューを送り、あなたがそれをレビューする時間がいつ確保できるかわからない場合、通常あなたが開発者に返すべき返事は、すべてを一度にレビューしなければならない1つの巨大な CL を送る代わりに、互いに構成されたもっと小さな複数の CL に分割してほしい、というお願いです。開発者には追加の作業が必要になるとしても、CL の分割は通常は可能であり、レビュアにとっても非常に助けになることだからです。
もし CL を小さな CL に分割することが不可能であり、あなたにコード全てを素早くレビューする時間もないときは、少なくとも CL の全体的な設計についてコメントをいくつか書いて、CL を改善できるように開発者に返信をしてください。レビュアとしてのあなたが目標としなければならないのは、開発者を常にブロックしないことであり、開発者が何らかの追加の行動を、コードの健康状態を損なうことなく素早く行えるようにすることなのです。
時間の経過によるコードレビューの改善
もしあなたがこれらのガイドラインに従い、厳しくコードレビューに取り組んだなら、時が経つに連れ、あなたのコードレビューのプロセス全体がどんどん速くなっていくことに気がつくはずです。開発者はコードが健康であるために必要なものが何かを学び、初めから優れた CL を送ってくるようになります。その結果、レビューに必要な時間もますます短くなっていきます。レビュアも素早く返事を書くことに慣れ、レビュープロセスに不必要なレイテンシーを加えないようになっていきます。しかし、想像上の速度を上げるために、コードレビューの基準やコードの質を妥協したりしてはなりません。長い目で見れば、そのようなことをしてしまうと、実際にはチームの速度をより遅くすることにしかなりません。
緊急事態
緊急事態と呼ばれる事態が起こったときには、CL はすべてのレビュープロセスを非常に速く通過しなければならず、品質に関するガイドラインは緩和されます。しかし、どのような事態が緊急事態と呼ぶ資格があるのかという基準については、緊急事態とはどのような時か？ を確認してください。
Next: コードレビューのコメントの書き方