コードレビューでの指摘分類FunctionalityとEvolvability、その比率の調査結果

"What Type of Defects are Really Discovered in Code Reviews?"というタイトルの論文がIEEE Transaction on Software Engineeringに掲載されている。分量の多い論文（2段組で20ページ弱、参考文献が70件以上）だが、示唆も多い。視点は実務に近いように思う。

論文は、ここ（IEEE digital library）から購入できる。また、ここ（Helsinki University of Technology）からダウンロードできる。詳細は原典を参照いただければと思う。

functionalityとevolvabilityは論文で提案されている欠陥分類。700件超のコードレビュー指摘結果と過去の研究結果とを踏まえて、大まかに2種類に分類していて、次のとおり。

• functionality欠陥
  機能欠陥の指摘。いわゆる潜在的バグの指摘。たとえば、予約システムにおいて「『予約の有効期間をすぎた場合には、1時間の猶予期間をもって予約を取り消す』仕様が実装されておらず、猶予期間なしに即時に予約エントリが消去されている」といったものだ。放置すると今回のリリースで問題となる点を指摘したものであり、短期的視点での欠陥といえる。
• evolvability指摘
  今後の保守・拡張性の問題となる指摘。たとえば、Cプログラムにおいて「入力バッファを確保するための配列buffer[256]に直接数字（256）が使われているが、定数宣言して一括変更できるようにしておくべき」といったものだ。バグには直結しないが今後のバージョンアップや流用において、問題となり得る点の指摘であり、長期的視点での欠陥といえる。

論文では、ある企業の商用開発での388件のコードレビューの指摘結果、ある大学でのコードレビューの学生実験での371件の指摘結果の2つを調査結果として報告している。調査結果では75%の指摘がevolvabilityに関するものだったそうだ。

調査結果は広範囲な調査とは言うには少し物足りないが、個人的には多くのソフトウェア開発にあてはまる傾向を表していると思う。

特に、今後の拡張性よりも、今回のリリースでの品質を上げることのほうが優先順位が高いプロジェクトでコードレビューを実施する際には、evolvabilityよりもfunctionalityに関する指摘をするよう、レビューアにあらかじめ伝えておき、レビュー実施中もレビューア間でそのことを共有する必要があるといえる。逆にevolvabilityを重視したい場合には、特に指定はしなくともコードレビューは効果的に働くといえるだろう。

ここを読まれている方々にも、functionalityが重視される場合には要件、設計レビューを、evolvabilityが重視される場合にはコードレビューを、と暗黙的に使い分けされているのではないだろうか？私が検討をご一緒した企業の方からも同様の話を聞くことが多い。紹介した論文はそれを整理、明示したものとして価値が高いように思う。