71-パフォーマンスへの道は地雷コードで敷き詰められている

「プログラマが知るべき97のこと」の71個目のエピソードは、ソフトウェアメトリクスに関する話です。このエピソードではパフォーマンスチューニングを例にあげ、コードのリファクタリングを行っていく場面で遭遇する地雷原について述べられています。ソフトウェアのソースコードは美しくシンプルであることが理想ですが、どうしても複雑な部分や依存関係が強い箇所はあるものです。通常、それらは大きな問題とはならないために放置されていくのですが、パフォーマンスを改善する必要がある時に牙をむくことがあります。
パフォーマンスを改善するようなケースでは、特定の部分（ホットスポット）だけを改善する事で解決するとは限りません。状況によっては広範囲に渡ってデータ構造から見直す必要もあります。そのような時、少しだけの修正のつもりが他の箇所を修正する事が必要になり、その修正をしているとさらに別のところがという悪循環で地雷が連鎖して爆発してしまうのです。はじめから理想的なソースコードとしておくことがベストですが、現実としてはある程度の所で妥協しなくてはならないため、このようなリスクは常にあると言っていいでしょう。
そのような問題を防ぐ手段としてソフトウェアメトリクスは有効です。ソフトウェアメトリクスは、ソースコードの依存関係や複雑性などを客観的に数値化する技術です。例えば、「forやifのネストが深いほどそのコードは複雑である」「１クラスに定義されたpublicメソッドの数が多いほど複雑である」といった基準でソースコードを検証します。しかし、ソフトウェアメトリクスは純粋にコードを計測するため、そのコードがどのような経緯でかかれたかは考慮しません。publicメソッドが大量にあるクラスはメトリクスのスコアは悪いでしょう。しかし、それはsetter/getterメソッドが大量に定義されているデータクラスであるからかもしれません。単純にメトリクスのスコアを品質評価基準にしてしまうと酷い目に合います。カバレッジと同じように１つの基準として参考にするという事が重要です。
ソフトウェアメトリクスはコードを診断するために利用できる手軽なツールです。ソースコードが健康かどうかの計測を行うことができます。はじめは余りにも多くの検証項目にびっくりしてしまいますが、様々なアラートを確認できるでしょう。ソフトウェアの健康状態は定期的に検診を行い、問題になりそうな箇所は早い段階で治療するようにしたい所です。
ええ、手遅れになる前に…。

プログラマが知るべき97のこと