ソフトウェアメトリクスによる品質分析の実案件への適用

ソフトウェアの品質を分析する指標の1つにソフトウェアメトリクスがあります。現在、実案件の品質分析に適用しているのですが、開発者へのヒアリング内容とメトリクスの傾向が合致していて、非常に面白いです。

ソフトウェアのメトリクスとは、ソフトウェアを計測する方法およびその尺度のことを意味します。（中略）メトリクスを計測し、複雑過ぎるロジックや洗練されないパッケージ構成を見直すことで、バグが少なく保守性が高いソースコードを維持できるようになります。

（中略）

メトリクスを用いると、特に以下の品質にかかわる問題を検出し、信頼性と保守性を高めることができます。

• 複雑なソースコードにはバグが潜在する可能性が高くなる
• 複雑なソースコードは読みづらく、テストもしにくくなる
• 複雑なクラス構造は理解するのが困難で、拡張性にも乏しくなる

http://www.atmarkit.co.jp/fjava/rensai3/eclipsetst03/eclipsetst03_1.html

メトリクスを計測するにはEclipseのプラグインを使うと簡単です。Eclipse Plugin Metricsとか。HTMLレポートをExcelに取り込めば簡単に分析できます。

複雑なソースコードはテストが困難

複雑なソースコードは入出力のバリエーションが増加するため、ホワイトボックステストが困難になる傾向があります。異常系のテストがおろそかになっていないか、カバレッジ情報と併せてレビューする必要があります。

複雑度メトリクスには、マッケーブのサイクロマチック数（McCabe's cyclomatic complexity）やネスト数があります。

大きなソースコードは内容の把握が困難

大きなソースコードは内容の把握が困難になるため、実装すべき処理の抜け漏れが発生する傾向があります。業務要件を満たしているか、業務と実装の両観点でコードレビューが必要です。

サイズメトリクスには、LOC（行数）やステートメント数があります。

カバレッジを取る

テスト項目の妥当性に疑問を持ったら、まずは現状確認としてカバレッジを取ることをおすすめします。実行されていない行が必ずあるはずです。それがユニットテストでの再現が困難なもの（環境依存の異常系など）かどうか確認しましょう。

カバレッジはdJUnitやEMMAを使えば簡単に取れます。

ただし、カバレッジが100%であっても妥当性は保証できません。ブラックボックスの観点で、テスト項目と業務要件の合致を確認する必要があります。これはレビューしかないですね。

メトリクスの落とし穴

メトリクスが基準値域に入っていても、必ずしも高品質なソースコードとは限りません。メトリクスの計測だけでなく、コードレビューを併せて実施する必要があります。

他の静的解析ツールと同様に、「なぜ」メトリクスを計測する必要があるのか、「なぜ」低品質なソースコードが信頼性を下げるのか、開発者が理解していなければ意味がありません。無理やり基準に収まるソースコードを書くのでは本末転倒です。

長期的な視点で最も有効な投資は教育です。

大学院で研究してた内容が直接業務で役立つなんてうれしい。SIerのスーツな現場でも意外とそういうことはあるもんです。