コードレビューの速度

コードレビューはなぜ速くすべきか？

Googleでは、個々の開発速度よりはチームの開発速度を最適化する。 コードレビューに時間がかかると、次のことが連鎖的に起こる。

それでは、どれだけ速くすべきか？

あなたが現在没入している状態ではない場合は、レビュー要請を受け取るとすぐする。業務日基準１日を超えない。翌日出勤して最初に処理すべきことだと考える。私たちのガイドラインに従えば、１つのCLは１日に数回レビューを受けることができる。

速度 vs 妨害

チームの速度より個人の速度を優先する時もある。あなたが没入して開発しているなら、コードレビューをするために途中で仕事を中断してはいけない。開発者が邪魔されると、再び没入するまでにかかるコストが高くなる。業務が完了したり、すでに没入が終わった後である昼食時間や会議後、あるいは休憩室に行ってきた後にレビューをする。

迅速な応答

コードレビューの速度を決定する要因は、レビューが通過するまでにかかった合計時間ではなく、応答時間である。もちろん、速く通過されることが理想的ですが、レビューメッセージを速くやり取りすることがより重要だ。応答が速ければ、作成者の不満が減り、プロセスが遅くないと感じる。

今忙しい場合は、いつ頃にレビューを開始する予定かを簡単に返信するか、他のレビュアーをお勧めする。もう一度強調するが、没入して開発しているなら、このような返信を送るために仕事を中断してはいけない。応答が早ければ良いが、レビュー自体は十分な時間を使うことで、いつもコード品質を保証します。

時差コードレビュー

作成者が別の時間帯にいる場合は、なるべく彼が仕事中の時に応答を送信する。そうでなければ、翌日出勤するまで応答するようにする。

不完全なLGTM （LGTM with Comments）

コードレビューの速度を上げるために、いくつかの問題を残したままレビューを通過させることもある。 このような時は、(1)今後CLには反映をするのか、それとも(2)必須ではないので、あえて修正しなくても良いのかをコメントとして残しておく。異なる時間帯にある開発者同士でコードレビューをする時にも便利だ。要求仕様が反映されるまでに少なくとも一日がかかるからだ。

巨大なCL

CLが大きすぎてレビューをするのが難しい場合は、小さなCLに分割してもらう。作成者としては追加の作業を行う必要があるが、レビュアーにとっては大きな助けになり、ほとんどは分離が可能だ。もし分離することができないか、レビューが長くかかると思われる場合は、設計に対する意見でもすばやく送信する。作成者にできるだけ早くコード改善作業を開始させることが重要である。

ますます良くなるコードレビュー

ガイドを厳密に守れば、コードレビューが益々速くなることが感じられる。作成者はもう少し基準に適合するドラフトを作成することになり、レビュアーたちも迅速に応答し始める。ただ、どんな状況でも、コードレビューの大原則は必ず守り、一時的な速度向上のために品質をあきらめてはいけない。

緊急事態

コードレビュー基準を緩和して迅速に通過させる必要があるCLもある。緊急状況ガイドを参考にして、どのような場合に該当するかを確認する。