Tricorder: Building a Program Analysis Ecosystem (ICSE'15) 読んだメモ
Googleが社内のほぼ全てのプログラムに対して静的解析を行うためのフレームワークTricorderを開発し、運用した知見を紹介する論文がICSE*1で発表されていた。OSS版の Shipshapeはgithubで公開されている。
研究として新しい点は特にないけど、現場目線かつGoogle規模の開発で実際に成果を上げている事例としてとても面白かった。
提案ツールはGoogle社内でメインに使われているレビューシステムと連携して動作するようになっており、 その上では一日に3万のchangelists snapshot(レビューの単位)が処理され、実際に9万件ほどの警告(未使用変数とか)がツールによって発見されている。 ただし、これは開発者がchangelistにおいて変更した部分以外に対する警告も含まれており（このあたり記述が曖昧） 開発者が実際に変更したコードに対する警告のみがレビューシステム上に表示されるようになっている。
レビューシステムに表示される警告には、
- レビュアーが利用できる"please fix"ボタン
- 無意味な警告が出た時に開発者が押せる"not useful"ボタン
- また機械的に修正を提案出来る場合には"Apply fix"ボタン
が表示される。
提案ツールはプラグイン方式を採用しており、既存のインタフェースを実装することで簡単に解析を追加できる。 また、これは並列度を高めることにも貢献し、数分程度で解析が終わるためコードレビューが終わる前に警告を出すことができている。 FindBugs, ClangTidy, Lintなどの既存ツールがプラグインとして組み込まれているほか、社内の誰でも好きなプラグインを開発することが可能になっている。
プラグインの開発自体はだれでも出来るものの、それを社内にロールアウトするためにはいくつかのガイドラインが提示されている。
- 実際に社内で稀だけど実際に起こっている問題を検出するものであること。こんなコード書かないよ、というような架空の問題を解決するものや、社内で頻繁に発生する（つまりとくに問題になってない）パターンを検出するようなものではいけない
- 誤検出(false positive)の割合が10%以下であること
- 可能であれば自動修正案を提示すること。これは問題が解決される可能性を高め、また開発者が警告の意図を理解するのに役立つ
- 警告文にはなるべくURLや詳細な説明を含めること
false positiveの計算には上述のレビューシステム上に提示されるボタンに対する開発者の反応を利用しており、 実際の開発者目線で提示される警告の有用性を測定し、プラグイン開発者たちが改善を行えるようになっている。
実際に現在のGoogle社内では30程度のプラグインが運用されており、一日あたり700回程度の"please fix"が押されている。 開発者がレビュアーに指摘される前に警告に気づくこともあるため、実際にはより多くの改善につながっているとのこと。 これにたいして"not useful"ボタンは一日平均50回程度しか押されておらず、false positiveの割合を少なく保った運用ができている。
また、ツールによって直接問題を指摘して修正させるだけなく、開発者がその問題に気づき同じ過ちを繰り返さなかったり既存のコードを修正することにもつながっているらしい。実際に、ツールで警告を出しはじめたあと、コードベース全体でみた類似の問題の合計数が減少するということがあったそうだ。
*1:ソフトウェア開発に関するトップカンファレンス
