はじめに
Googleではコードの品質向上のために、独自の「バグ予測アルゴリズム」という仕組みをもっていて、バグが含まれているであろうソースコードを予測しながら開発を行っているそうです。
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。
そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している − Publickey
Googleが採用しているバグ予測アルゴリズムの概要
Googleが採用しているバグ予測アルゴリズムの仕組みを簡単に説明すると、以下のようになります。
より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなります。そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムが示すところです。
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している − Publickey
集中的に修正されたソースコードにはバグが含まれている可能性が高い、ようするにコミット回数が多いソースファイルにはバグが含まれている可能性が高いと考えることができます。
そこで、このエントリではSubversionでバージョン管理をしている開発プロジェクトにおいて、コミット回数が多いソースファイルを特定する方法について紹介します。
statSVNでコミット回数の多いソースファイルを特定する
statSVNというツールを使うとコミット回数の多いソースファイルを特定することができます。statSVNは、Subversionリポジトリの利用状況をログファイルから集計して、グラフや一覧表を出力してくれるOSSのツールです。
statSVNの使い方については以下のエントリを参照してください。
このstatSVNが出力するデータの１つに、"Files With Most Revisions"というものがあります。これは、コミット回数の多いソースファイルのランキングです。
上記の画像はstatSVNプロジェクトのリポジトリを例としていますが、changes.xmlが特定の期間で54回修正されていることを示しています。
"Files With Most Revisions"を見ればコミット回数の多いソースファイルは一目瞭然ですので、レビュー時や修正時に注意を払うことができます。
修正していないソースファイルを除外する
開発プロジェクトによっては何年、何十年もの間、エンハンスを重ね、既存ソースが大量にあるところもあると思います。既存ソースのコミット回数を無視したいという場合には、statSVNで集計する期間を絞ることができます。
statSVNはSubversionが出力するログファイルを元に集計してデータを出力します。Subversionでログを出力する際に、日付やリビジョンを指定して範囲を絞ることで修正していない既存ソースを除外し、純粋に開発中のソースファイルのみを集計対象にすることができます。
たとえば、Subversionで日付指定でログを出力する場合には以下のようなコマンドを実行します。
svn log -r {2008-01-01}:HEAD URL
おわりに
statSVNでGoogleのバグ予測アルゴリズムを完全に再現できるわけではないですが、似たようなことはできると思っています。修正回数の多いソースファイルが分かれば、レビュー回数を増やしたり、テストを入念にするなど、何らかの対策が施せるのではないかと思っています。
オーム社
売り上げランキング: 38477
