JUnit 4.5で学ぶメトリックス・ツールの使い道
また予告とぜんぜん違う内容ですが、Rationalに面白いツールがあることを最近知った（いいのか、社員なのにこれで……）ので、今回はこのツールについて書いてみます。
Javaの案件だと大抵コード・インスペクション・ツール（静的テスト・テスト・ツールとも）としてCheckstyleとFindBugsをセットで使用することを義務付けていることが多いと思います。
これらのコード・インスペクション・ツールはルールの選択が難しくて、うっかりデフォルトの設定で使った日にはあまりのルール違反の指摘の多さに「ウゼー」と感じて、「狼と少年」状態になっていつのまにかオフにされていたとかいうことになりかねません。というか、僕もまことに申し訳ないことに、そういうことをしていた時期がありました。
でも、仮にもテストの専門家としてプロジェクトに参加することが多い僕がそのようなことをしていると、ほかの開発メンバーにとって示しがつかないだけでなく、お客様への背信行為となってしまいます。ですので、今はまず、ルールの策定段階から自分も関わるようにしています。そして、そのルールの策定では開発効率は落とさないが、しかし、潜在的なバグは事前に可能な限り自動的に除去できるようなルール選びがポイントになります。
同時にもうちょっとマニアック……じゃなくて、定量的な品質測定を考慮したプロジェクトですと、JDependのようなメトリックス・ツールを併用していることもあるかと思います。
サイクロマチック数のようなよく知られているメトリックスであっても、プロジェクトで実用的に活用するのはなかなか難しいです。僕がこれまで参加したプロジェクトでも、あくまで参考程度に使用していることがほとんどで、効果的に活用できているという事例には遭遇したことがありません。
冒頭の「面白いRationalツール」とは、このコード・インスペクション・ツールとメトリックス・ツールがセットになったRational Software Analyzerという静的解析ツールです。
これのどこが面白いのかというと、僕もほかの方からお勧めされるまでは単なるコード・インスペクション・ツールなのだろう、フリーで十分ではないかと思っていたのですが、面白いのはコード・インスペクションの部分ではなく、メトリックスの部分なのです。
というかですね、提供されているメトリックスがマニアックすぎて、見方が分からなかったりします……。不勉強なのか、半分以上分からないメトリックスでその値が何を示しているのか分からないのです。これでも一応、情報工学専攻のソフトウェア工学研究室出身です。
そのようなものをお金出して買う価値があるのかということですが、ある意味ソフトウェア工学に対して不勉強なエンジニアに対する挑戦といえましょう。Rational Software Analyzerの出してくるメトリックスも分からないようでは、真のソフトウェア・エンジニアとはいえないのです！ ああ、でもマニュアルを見てもメトリックスの説明が書いてないのだけど……。もうちょっとマニュアル充実して……。せめて推奨値ぐらい書いてよ……。あ、これ自社製品だった……。
さらにもうひとつ、クラス間の関係からアーキテクチャの良し悪しを計ったり、使われているデザイン・パターンを抽出したりするJavaアーキテクチュアル・ディスカバリーなる機能もあります。これまた不勉強ながら知らないデザイン・パターンとアンチ・パターンがてんこ盛りです。勉強しろよって感じですが。
それはさておき、実際にどんなものかと使ってみました。さすが過去に参加したプロジェクトのソースコードなどを使うわけにはいかないので、ここはオープンソースの定番で、僕も3.8時代にコードを全部読んだことがあるJUnitの4.5を被験者としました。
・・・
・・・
・・・
例
ルール
Assert.java: 623 String.equals("")を呼び出して、文字列の長さを検査しない
コード
if (message != null && !message.equals(""))
推奨コード
if (message != null && message.length() != 0)
著名なオープンソースであるJUnit4のコミッターをしてこのようなコードを書いているのかとちょっと安心した（笑）。
あ、いや、修正前のコードは別に間違いではないではないのですが、パフォーマンスを厳密に考慮する場合、修正後のコードの方が良いよねということです。
こんな感じで、コード・インスペクションについては単体テストで見つかるバグというよりは、どちらかというと潜在的に問題になりそうなコードを指摘してくれるルールが多いです。CheckStyleとFindBugsでも同じですが、ルールを全オンにしたりするとあまりに指摘が多すぎて厳しいので、ルールはプロジェクトに応じて絞り込んだ方が良いです。運用についても、常時オンというよりはEclipse内だけでなく、ビルド時にも組み込めたりするので、1日1回とかコミット前とかそういうタイミングで潜在エラーの可能性を見るために使うというのがよいと思います。
メトリックスについては、かろうじて理解できたのは複雑度メトリックスである循環的複雑度（つまりサイクロマチック数）ですが、閾値の6を越えているのはわずか6クラスと非常にシンプルに作られていることが分かります。かつて某金融機関システムのコードで、6000行のメソッドで8重ループの、ある意味「神」なコードを見たことがありますが、そのような破壊力を持つコードはJUnit 4.5には存在しないのです。というか、そんなコードは仕事以外では絶対読みたくありません。仕事でも読むのはしんどいです。
ただし、JUnit 4になってからの各種の機能追加によるものか、アーキテクチュアル・ディスカバリーを見てみると微妙に構造レベルのアンチ・パターンが存在していたりします。さすがに恐れ多くもJUnitなので、コンポーネント間の循環参照（Component Cyclic Dependency）は起こしていませんが、単なる中継だけのクラスと化しているような微妙なクラスもちらほらあります。メトリックスはあくまで指標なのであえてパターンを破っていたり、あえてアンチ・パターンを実装していたりすることもありますが、そこら辺はバランス感覚でしょう。
そんなわけで、微妙に使いこなすのは難しかったりするRational Software Analyzerですが、メトリックス好きやオブジェクト指向のパターン、アーキテクチャとは何であるかとか日夜悩んでいる方には熱いツールだと思うので、ぜひ一度、体験版を入手して（あ、また最後に宣伝）、自分で書いたソフトウェアやらオープンソースのフレームワーク、はたまた許可が下りるなら現在参加されているプロジェクトのソースコードに対して実行してみてください。
完璧にメトリックスを使いこなせて、プロジェクトで指標として使えるようになれば百人力だと思います。奥義を極めるためには論文も含めたメトリックス本と格闘ということになる奥深いツールだと思います。
ボーナスで買ってやるぜという漢気あふれる方がいらっしゃいましたら、ぜひ個別にご連絡ください。割引……はできないと思いますが、冬休みにでも濃い勉強会をご一緒にしましょう。