コードレビューでは同じような修正を何度も繰り返しているしているように見えるという知見は、 if 文に関する下記の研究で判明していました。
この研究の続きとして、コードレビューで行われた任意の修正のうち、何度も繰り返されているものだけを取り出すパターンマイニング手法を定義し、さらに調査してみました。2019年2月に開催されたソフトウェアクローンに関するワークショップ（IWSC 2019）にて、以下のタイトルで発表しています。
Mining Source Code Improvement Patterns from Similar Code Review Works
この研究では、過去の研究と同様に、投稿されたパッチの最初の版と、レビューが完了してソースコードに取り込まれた最後の版の差分を分析しています。レビューによる差分として、たとえば以下のような情報が取得できます。
- i = dic["key"]
+ i = dic.get("key")
この研究では、この差分内容自体から、「よくある修正」のマイニングを試みています。具体的な方法としては、以下に示すように、コードレビュー差分情報を含めたトークンの系列を生成しています。
i = dic
- [
+ .get(
"key"
- ]
+ )
行の先頭に "-" が付いたものがレビューで削除されたトークン、"+" の付いたものが追加されたトークンです。i=dic、"key" という行については変更されていないことを示しています。
パッチをそれぞれこのような系列に変換した後、数値は NUMBER に置き換えるなど少し正規化操作もかけてから、系列データマイニング（Sequential Pattern Mining）のアルゴリズムを実行します。これによって、よく行われている修正と、その前後にいつも出現しているトークンを抽出しました。マイニングのアルゴリズムには、動作原理が分かりやすく、そこそこの性能を持つ PrefixSpan を使いました。
OpenStack プロジェクト群の 616,723 個の変更に対してマイニングをかけた結果から得られたパターンには色々含まれていました（詳しくは論文の Table 1参照）。たとえば、以下のパターンは、1,149個の変更に出現していました。
self.assertEqual
+ NUMBER ,
- , NUMBER
これは、self.assertEqual(_, NUMBER) が self.assertEqual(NUMBER, _) に置き換わっているらしいことを示したパターンになっています。assertEqual の第1引数に期待された値、第2引数に実際のプログラムから計算された値を入れるので、それを守っていなかったテストコードを修正してきたことがうかがえます。このパターンを含めて、出現頻度の高いパターン群 5個について StackOverflow に対応する質問が見つかりましたので、「一度は解説を読んだことがないと分からない」というタイプの知識が、開発者にうまく広まっていない可能性があると考えています。
修正パターンのうち、修正回数が 5,000回を超えていたものは2つでした。その１つは単体テストの TestCase クラスに関する関数呼び出しを置き換えるものです。
self.
+ stub_out
- stubs . Set
)
この置き換えの理由については、以下のように API ドキュメントに記載されています（レビューが行われた時期とドキュメントに書かれた時期のどちらが早いのかまでは、残念ながら分かっていません）。
stub_out(old, new)
This should be used instead of self.stubs.Set (which is based on mox) going forward.
こちらはプロジェクト固有の事情によるところがありそうで、先ほどのテストの書き方よりも、さらにマイナーな知識になっていることが、この修正回数に反映されているように思います。
開発者が新しいルール（たとえば使うべきでない機能）を定義し周知できればそれで良かった可能性もありますが、なるべく手間を発生させないために、このような新しいルールの出現を自動で検知し、開発者にうまく伝える仕組みというのも、研究室で今後の課題として考えていく予定です。
（ 2019年3月5日追記）本論文は、IWSC2019 において参加者の投票によって People's Choice Award に選ばれました。受賞に関するページにて、ワークショップで使用した発表スライドを公開しています。
