コードレビューで開発者はどのぐらいコメントをしているのか、私たちの研究室で調べた論文が電子情報通信学会の英文誌に掲載されました。J-STAGEからどなたでもダウンロードすることができます。
この論文では、Chromium、AOSP、Qt、Eclipse、LibreOffice という大手プロジェクトでのコードレビューにおいて、コメントの数と、コメントの長さ（単語数）が時間経過・レビュアーの経験によって変化するかを調べました。論文の調査結果から言えること（Implications）としては、以下のようなものがあります。
- コードレビューのコメント数は平均すると3～13。１コメントは平均22単語。プロジェクトによっても大きく異なる。
- コメントの数や長さは時間によって変動する。システムが成長するにしたがって増えていく傾向はあるようだが、開発者もレビュアーも相手のコメントのうち必要なもの・興味のあるものにだけ反応するので、必ずしもそうとは言えない。
- 上記２つの結果から、「このぐらいコメントをしたからレビューもそろそろ終わりだろう」というような予断はできないということになる。
- 開発者は経験が少ないと、レビュアーは経験が多いと、コメントをたくさん書く傾向にある。もちろんパッチの長さもコメントの量に影響する。パッチに関する議論を短く済ませたい場合は、経験とパッチの長さの両方に気を付ける必要がある。論文には明記されていないが、議論が短くてもバグを見逃したら意味がないし、開発者が経験を積むにも時間が必要なので、たとえば開発者は経験を積むまでは小さなパッチ投稿（で済みそうな Issue の解決）からやっていくというのが良いのかもしれない。
本当は「このぐらいレビューコメントを書くのが基本ですよ」というようなガイドラインが出ればよかったのでしょうが、残念ながらプロジェクトによる、時期にもよるで、そういう話にはなっていません。この研究はコメント量の話だけで、検出されたバグの数に関しても考慮していないので、活動量に対する効果まで議論できるようになるにはまだ研究が必要なのだろうと思います。
ちなみに、論文ではプロジェクトに投稿されたパッチ数（Workload）とコメント数の関係も調べていて、影響が小さいことが図表に出ています。プロジェクトが忙しくとも、レビューの活動量に影響が出ていないということは、「忙しいからレビューを簡略化してしまってバグを見逃す」ということはないのかもしれません。こちらも、バグの検出数などをうまく調べることができるようになれば、今後、細かい議論ができるようになるかもしれません。
