bugspotsはgoogleが開発した、バグ予測アルゴリズムをオープンソースとして開発されたツールです。
細かい説明は後にまとめますが、実際に使ったのを見るほうが分かりやすいので早速使ってみます。
##実際に使ってみる
1.bugspotsをgemでインストール
#Gemfile
gem 'bugspots'
#terminal
bundle install
2.githubのリポジトリを指定して実行する
#terminal
bugspots #{path to リポジトリのrootフォルダ}
3.結果を見てみる
このHotspotsの下に出力されている左の数値がバグが起こりやすい度合いを表すスコア、右が対象のファイルになる。
メチャクチャ簡単に導入できるので、
リファクタやコードレビューなどで目星をつけるという意味では有用なツールな気がしました。
##背景の説明
googleでは、チェックイン前にユニットテストやコードレビューが行われているが、コードが大量になってくると、ユニットテストやコードレビューをすり抜けたバグも少なからず発生してします。
googleではこの問題に対処するために、独自の「バグ予測アルゴリズム」を採用して、コードの品質向上を図っているらしいので、そのアルゴリズムについて調べてみました。
ソフトウェアなどのバグ発見手法には、「ソフトウェアメトリクス」というものがあります。
##ソフトウェアメトリクスの特徴
- ソースコードを静的に分析
- モジュールや関数の行数、ネストの深さ、モジュール間の依存度合いなどを数値に置き換える
- 2で算出した数値を元にバグが起きやすい箇所を推測する
この手法でのバグ推測ツールは今でも様々なベンダーから市販されています。
ただし、googleは動的なソースコードの編集履歴を基にした、もっとシンプルな方法でバグを推測するアルゴリズムを開発しました。
##googleのバグ予測アルゴリズムの特徴
- gitやsvnのバグトラッカーとコミットログを基に推測する
- バグフィックスのコミットが何回行われたかが肝になる
※コミットログのコメントの中で'fix(es|ed)?|close(s|d)?'の正規表現にヒットするコミットをバグフィックスと見なしている。コメントを日本語で残しているなら、"修正"とかしてもいいかもしれない。
実際の数式がこちら。
nは、コードに対してバグフィックスが行われた回数を示します。tiは修正が行われた時点のタイムスタンプで、コードが生成されたときを0、現在を1と置いて、その間の少数値をとります。つまり、1月1日にコードを書き始め、今日が1月30日であるとすると、15日にバグフィクスをしたらti＝0.5になります。
ti＝0のとき、1/(1＋exp(－12×ti＋12))≒0 となり、
ti＝1のとき、1/(1＋exp(－12×ti＋12))＝0.5 となります。
tiをx軸、scoreをy軸にしてみたグラフはこうなる。
バグ修正の回数だけscoreが合計され、その合計スコアがバグが起きやすい度合いを表すスコアになる。
##まとめ
より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなる。
そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムの意味になります。