読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

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

SIer メトリクス

ソフトウェアの品質を分析する指標の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のスーツな現場でも意外とそういうことはあるもんです。