Speed of Code Reviews を読んでのメモ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

miso_soup3 Blog