品質管理ツールSonarの記事

@ITにおかもとさんが品質管理ツールSonarの記事を書いておられたのでメモ。

【元ネタ】
コード探知機「Sonar」でプロジェクトの深海を探れ！ (1/4) - ＠IT

Sonarでソースの品質をチェックする: プログラマの思索

メトリクスでソフトウェア品質を見える化する: プログラマの思索

複雑度と単体テストケース数の相関関係: プログラマの思索

Sonarはインストール出来ていたものの、使いこなせてなかったので、とても参考になる。
Sonarで一番知りたいメトリクスは複雑度だ。
複雑度と単体テストケース数の相関関係: プログラマの思索でも書いたけれど、複雑度と単体テストケース数は密接に絡んでいる。

ソフトウェア複雑度(McCabeのサイクロマチック数)
≒分岐網羅(C1)のテストケース数
≒単体テストケース数
という関係があるから、複雑度が大きいほど単体テストケース数が膨らむ。
たとえJUnitで単体テストを自動化していても、複雑度が大きすぎるプログラムはどこかにバグが潜んでいる。

IF文やFor文がたくさんネストしているプログラムは、それだけで簡単に複雑度は30以上は超える。
おそらくどんなシステムでも、複雑度が30を超えるプログラムは10個ぐらいはあるように思う。
特に本番稼働後、たくさんのパッチを当てる度に複雑度は増していく。

他の会社では、複雑度が15以上のプログラムはコードレビューを必須として、30を超えたら書き直すかどうか方針を下すという話を聞いたことがある。

個人的には、複雑度が30以上のプログラムは、リファクタリングして書き直した方が、その後の結合テストでも修正しやすいし、リリース後の運用保守でも機能追加しやすくなると思う。
こみいったプログラムの保守ほど嫌な作業はない。
プログラムに手を入れて変更するだけで、新たなバグを作ってしまう可能性が高いからだ。

SonarやStatSVNなどのメトリクス出力ツールを使って、いつでも開発者が自分たちのシステムの品質を見るようにすれば、自然に綺麗なプログラムを書こうという意識が生まれるだろう。
品質の見える化は開発者のプログラミング作法を自然に変えてくれるはずだ。