コードレビューの考え方
以前以下のようなブログを投稿した。 daikichi.hatenadiary.com
今回、すこしばかりコードレビューに関する数値的な文書を読んだのでその内容を元に以前の投稿の答え合わせ的な意味をこめてコードレビューについての考えをいくつか記述することにする。
Code Reviews Do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down https://www.microsoft.com/en-us/research/publication/code-reviews-do-not-find-bugs-how-the-current-code-review-best-practice-slows-us-down/?from=http%3A%2F%2Fresearch.microsoft.com%2Fapps%2Fpubs%2F%3Fid%3D242201
考察に利用出来そうな情報は以下。
- コードレビューにおいて機能的欠陥に関する指摘が行われるのは全体の15%
- コードレビューにおいて長期的な品質に関する指摘が行われるのは全体の50%以上
- ある部分のレビューをする場合、レビュアーの経験がない開発者の有用性のあるレビューは33%、レビュアーの経験が３回以上になると、有用性のあるレビューは67%となる、レビュアーとなることで高速な学習を行える
- レビューの有用性はレビュー規模が大きくなるにつれて下がっていく
レビューの目的を考える
コードレビューに求める効果は以下のようなものがある。
- 実装・設計の共有
- 不具合の発見
- 保守性の確保
このうち、先に上げた情報を参考にすると機能的欠陥に関する指摘は15%となり、不具合の発見にはそれほど効果がないものと考えられる。
一方、保守性の確保については50%以上の指摘が行われており、コードレビューはプロジェクトの長期的な保守性の確保に大きな効果があると考えられる。
実装・設計の共有についてはどうだろうか？
ある部分のレビューをする場合、レビュアーの経験がない開発者の有用性のあるレビューは33%、レビュアーの経験が３回以上になると、有用性のあるレビューは67%となる、レビュアーとなることで高速な学習を行える
ある実装に対して、レビューを複数回行うと有用性のあるレビューを行う量が飛躍していくことが伺える。
コードレビューを行うことはレビュアーが該当箇所の実装・設計情報を学習する効率的な場であると考えられるだろう。
これらの情報をまとめると、コードレビューは保守性を確保し、実装の情報をコードレビュー参加者内で共有するために行うもの、また、不具合の発見にはそれほど高い効果は無いと考えられるだろう。
レビューの規模を保つ
レビューの規模が大きくなるにつれてレビューの有用性が下がっていくのならば、レビューはできる限り小さい単位にまとめなければならない。
以下のようなコードレビューリクエストはレビューを行う前に、分割して再提出することを要求することを検討したほうが良いだろう。
これに関しては機能の正しい分割・境界の理解の共有にも役立つことが考えられる。
コードレビューを通すことでチームとしてのスキルをフラットにすることに効果があるだろう。
このデータを元にした考え方はチームにコードレビューを行う文化が無い場合に、なぜコードレビューをするのか？というのを説得する材料として利用できそうだ。
すでに文化があるチームに関してはレビューの方法を検討する材料にもなるだろう。
