miso_soup3 Blog

主に ASP.NET 関連について書いています。

Speed of Code Reviews を読んでのメモ

GoogleHow to do a code review のドキュメントを公開しました。いくつかのセクションのうち、レビュアーのための1つ Speed of Code Reviews を読んで、読み取ったものをメモします。

※ 日本語に翻訳されたプロジェクトがあります: Google エンジニアリング・プラクティス ドキュメント | eng-practices

なぜコードレビューは早くするべきか?

Googleは、”個人”の開発者のコードの書く早さを最適化するのではなく、開発者の”チーム”が一緒にプロダクトを作る早さを最適化する。個人の早さは重要だが、チーム全体のベロシティほど重要ではない。

レビューが遅いとき、次のことが発生する:

  • チーム全体の速度が低下する
    • レビューにすぐに反応しない人は個人として別の仕事を完了できる。ただし、他のチームメンバーの機能開発やバグフィックスは、レビューと再レビューを待ち、数日、数週間あるいは数ヶ月遅れる。
  • レビューのプロセスに不服を唱える
    • レビュアーが数日毎にレスポンスしたとき、そしてその度に大きな変更を要求するとき、開発者はイライラして苦しくなる。これは、レビュアーの厳格さに関する苦情となる。もし同じような変更を要求しても、それが素早いレスポンスであれば、その苦情は消える傾向がある。コードレビューのプロセスの苦情のほとんどは、素早い対応で解決される。
  • コードの健全性に影響を与える可能性がある

どれくらい早くするべきか?

集中しているタスクの途中でない場合は、レビューがきたらすぐに行う。

最大、1営業日までに応答する。つまり、翌朝の最初に行う。

これは、典型的なコード変更は、1日以内に複数回のレビューを受ける必要があることを意味する。

早さ vs. 割り込み

個人のベロシティを考慮することが、チームのベロシティに勝る場合がある。もし、集中しているタスクの途中の場合は、自身をコードレビューで中断しないこと。

コーディング中に中断することは、別の開発者にコードレビューを待ってもらうことよりも、実際にはチームにとってコストがかかる。

代わりにブレイクポイントを活用する。例えば、コーディングが完了したとき、昼食の後、キッチンから戻ってきたときなど。

早いレスポンス

ここでの早さとは、レビューが通過するまでの時間の早さではなく、個々のレビューに応答しているときの時間早さを言う。

全体のプロセスも高速である必要があるが、それよりも、個々の応答が迅速になることが重要。

忙しくてレビューをできない場合:

  • 開発者にいつできるかを知らせるクイックなレスポンスを送信
  • より迅速に対応できる他のレビュアーを提案
  • 最初に大雑把なコメントを提示する provide some initial broad comments

コメント付きのLGTM

コードレビューを高速化するために、まだ未解決なコメントを残していたとしても、LGTM/Approval を与えるべき特定の状況がある。これは以下のいずれか:

  • レビュアーは、開発者が残りのコメントに適切に対処すると確信しているとき
  • 残りの変更はマイナーで、その開発者によって行われる必要はないとき

レビュアーは、上記のいずれであるかを明記しよう。

コメント付きのLGTMは、例えば、レビュアーと開発者が違うタイムゾーンにいるとき特に一考価値がある。そうでなければApprovalを得るために丸1日待つことになってしまう。

コードの変更は小さく

レビューをする時間があるかどうか分からないほど誰かが大きなコードレビューを送ったとき、あなたの典型的な応答は、開発者に小さなコードの変更に分割することを求めること。

もし、コードの変更を小さく分割できなかったり、あなたが全体をすぐにレビューする時間がないときは、少なくとも、全体的な設計に関するコメントを書いて、開発者に改善のために送り返すこと。

レビュアーのゴールの1つは、開発者をブロックしないこと。開発者がコードの健全性を犠牲にすることなく、追加のアクションを迅速に実行できるようにすること。

長期にわたるコードレビューの改善

これらのガイドラインに従って厳格にレビューしたとき、コードレビューのプロセス全体が時間とともに早くなる傾向があることに気づくはず。

開発者は、健全なコードに必要なものを学び、最初からすぐれたコード変更を送信し、レビュー時間を短縮する。

レビュアーは、遅延せずに迅速に対応することを学ぶ。

ただし、ベロシティを早くするために、code review standards や品質に妥協してはいけない。それは長期的にみれば、実際には何も実現していない。