View on GitHub

google-engineering-practices

Google's Engineering Practices Documentation Japanese Translation

コードレビューのスピード

なぜコードレビューは早くなければならないのか?

Google では、開発者のチームが1つの製品を協力して開発する速度を最適化しています。これは、個人の開発者がコードを書くことができる速度を最適化するのとは逆です。個人の開発者の速度が重要なのは確かですが、チーム全体の速度と同じくらい重要というわけではありません。

もしもコードレビューが遅かった場合、以下のような問題が起こってしまいます。

コードレビューはどのくらい速く行うべきか?

集中状態にあるタスクがない場合には、レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません。

コードレビューリクエストに対して、返事をするまでに掛けることが許される最大の時間は、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: コードレビューのコメントの書き方