Test::Perl::Metrics::Liteでコードの”死活”監視

複数人で開発していて、コードベースが管理できないくらいに複雑化してしまうというケース、誰もが1回は経験したことがあるのではないかと思います。それを防ぐために、問題のあるコードに対してアラートをあげるのをテストで行うためのモジュールが、Test::Perl::Metrics::Liteです。拙作のPerl::Metrics::Liteを用いたテスト用のモジュールです。　

コードの問題の早期発見に関しては、メトリクスの可視化という手段が有効に機能します。色々な例外ケースを考えると、一律の閾値を設定することは難しいため、閾値によってエラーにするのではなく、可視化のみにするというのは割とよくある運用方法の一つです。これは、Gangliaなどでのシステム状態のモニタリングと似ています。このような用途では、先に紹介したPerl::Metrics::LiteによるJenkins+CheckStyleとの統合がおすすめです。

一方、どうしても認められない限界の許容値というのを設定することで、アラートをあげるという使い方もメトリクスにはあります。多様なレベルの開発者が参加する際には重要です。このような場合は、閾値は若干緩めに設定し、どうしても超えてはいけないラインを設定することで、コードが管理不能にならないようにコードベースを死守するために使います。概念としては、Nagiosなどを使った死活監視の概念と似ています。100行を超えるようなメソッドがコミットされる状況を監視するというのは、コードの死活監視といっても過言ではないからです。

Test::Perl::Metrics::Liteは後者のコードの死活監視を行うためのモジュールで、JenkinsなどのCIシステムとして統合して使うことを想定しています。

使い方ですが、以下のようなテストファイルを作り、これをCIで継続的に実行します。

ex) code_metrics.t

use Test::Perl::Metrics::Lite (-mccabe_complexity => 20, -loc => 100);
BEGIN {                                                                                                                                
    all_metrics_ok();                                                                                                                  
} 

上記の例は、コメント抜きの実行数が100行を超えていて、mccable complexityが20以上という条件で多数の分岐のある複雑なメソッドが引っかかることになります。この条件だと、そう簡単に手をつけられる状態ではなく、そのコードはほぼ死にかかっているといっても過言ではありません。このようなケースは、ビルドレベルでエラーにするというポリシーをとっておかないと、後々プロジェクトが崩壊してしまうため、テストケースという形で継続的にビルドするのに向いています。

まとめ

技術的負債を抱え込まないようにするために、メトリクスの可視化だけでなく、メトリクスによるコードの”死活”監視もすると捗るぞ、ということになります。

静的言語では、その言語の性質上このようなツール群はとても充実しているんですが、LL界隈ではあまり充実していないため、少し作ってみました。是非活用していただければ。