ソフトウェアメトリクス

メトリクス測定

最近、ありえないほど酷いソースコードJava による Web システムに遭遇したので、いい機会だしソフトウェアメトリクスを測定してみた。(言うまでもなく、そのプロジェクトは火が噴いて大変な状態だった)

ソースコードをわざと難読化しているとしか思えないくらい無意味に複雑な実装で、TDD(テスト駆動開発)などを実践しアジャイル開発に取り組んでいる者としては、あまりの世界観の違いに驚いてしまった。

アーキテクチャ自体が終わってる印象なので、当然の帰結とも捉えられるような気がするが、あまりにも・・・。

とにかく、Eclipse Metrics plugin を使ってメトリクスを計測してみたところ主な結果は以下の通りだった。

  • 10以下が望ましいとされる VG(メソッドのサイクロマチック数)で 50以上が数十箇所、最高値は 90を超えてる
  • MLOC(メソッド単位の行数)の最高値が約 500行
  • NBD(メソッド内の最大ネスト数)の最高値が 10を超えてる
  • NOI(インターフェース数)は 0

なお、Eclipse Metrics plugin ではコードクローン率が調べられないが、これを調べていれば更に驚きの結果になった事だろう。

継続的インテグレーションツールとメトリクスの連携

ふと思ったのだが、継続的インテグレーションツールを使ってデイリービルドする際に、ついでにメトリクスを測定しておいて、最新ソースコードのメトリクスがいつでも参照できるようにするとか、結果の履歴を管理するとかできると結構良いかも。

すでに、メトリクスサーバーとかがあったりして。

Eclipse Metrics plugin で出力した XML をスクリプトで処理

Eclipse Metrics plugin は出力結果をグラフ化する機能がないようなので(もうひとつの Eclipse Metrics Plugin は充実しているみたいだが)、出力した XML ファイルから閾値を超えたものを抽出して CSV 形式で出力するスクリプトを Groovy で書いてみた。

Groovy の GPath を使えば比較的簡単に XML を処理できる。

import java.io.*

def doc = new XmlSlurper().parse(new File("metrics.xml"))

//メソッドのサイクロマチック数に関する結果を抽出
def metric = doc.Metric.find {it.@id == " VG"}

//サイクロマチック数が 20を超えるものを抽出
def list = metric.Values.Value.findAll {it.@value.toInteger() > 20}

list.each {
    //it.@package の記述でエラーが出たため、代わりに it.'@package' を使用
    println "${it.@value}, ${it.'@package'}.${it.@source}, ${it.@name}"
}

なお、上記スクリプトの Metrics・Values・Value は XML の要素、@id や @value などは XML の属性に該当。