Devel::Cover::Report::VimででC0なカバレッジのコードを vim で表示

secondlifeさんのsimplecov-vimのエントリ見ていいなと思ってたんですが、perlでもDevel::Coverのreportとして実装されてました！
http://subtech.g.hatena.ne.jp/secondlife/20120312/1331528672

cover -report vim

でreport(cover_db/coverage.vim)を生成してから、vimで

:so cover_db/coverage.vim

を実行すると、以下のようにC0なコードがvim上で表示できます。エディタ上で気軽にカバレッジがみれるのはいいですね。

coverage.vimをみた感じだと、ちょっとした修正で、rubyやperlに限らず色々と応用できそうなので、今後他の言語でも使っていきたいところです。

Software Engineerにお勧めの技術書

人に聞かれることも増えてきた昨今ですが、お勧めする本は毎年そう変わりはしないのでまとめてみました。言語に依存する本は、書き出すと多くなってしまうので除いてます。

コンピュータサイエンス関連のおすすめ本

Computer Architecture

大規模なシステムを組む場合、高い性能を要求される場合、省リソースが求められるケースなどは、特に低レイヤへの理解の必要性を実感することになります。
下のレイヤを深く理解しておかなければ、このようなシステムのアーキテクチャデザインやトラブルシューティングは実質できません。

/高性能コンピュータ技術の基礎

    • 最新のプロセッサのアーキテクチャがどのようになっているのかを丁寧に解説しており、最近のプロセッサの全体像を把握するのに役立ちます。
OS/Linux Kernel
Algorithm/Data Structure

設計関連のおすすめ本

Software Architecture

と合わせて読みたい。Architectureという分類に入れるべきかは微妙なところもありますが...

Software Architectureを考える上で、Computer ArchitectureやArchitecture Patternだけではないというのは、企業で物作りをしている方は感じることがあると思います。以下の本は、Software Architectureをどのような視点で評価するのかということに対して、大局観を与えてくれるものです。

Design Pattern

GoFのパターン本以外にも読んでおくべきパターン本はあり、特にConcurrencyに関連する以下の本はおすすめです。

/ 増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
/ Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

Testabilityの高いDesignをするための本

Robert C MartinシリーズとMartin Fowlerシリーズを読んでおくのがおすすめです。

, 実装パターン

OOA/D
Developer Testing
System Design (Scalability)

Scalabilityという切り口でまとめるのがよいか微妙なところもありますが、Web系システムのScalabilityに関しては、
以下の本がおすすめです。

Webシステムのデザインであれば、上記の本を読むのでも十分得られることはあると思います。
この分野は類書は数多くありますが、幾つか上記の本を読んだら、分散システム, OS, Database関連の本やHPCの分野の論文などを良く読んだほうがよいです。

DB Design

データベースは、システム開発をする上では避けて通ることのできない分野です。DBはOSとStorageに強く依存しているため、DBのArchitectureだけでなく、ストレージ/OSのアーキテクチャも良く理解しておく必要があります。

データモデリングは、OOA/D と同じくかなり癖のある分野で、これがベストであるといいきれる本はないのですが、以下の本は総じておすすめではないかと思います。ある程度読んだら、キーとなるドメインの知識獲得のほうを大事にしたほうがよいです。

/達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

      • セルコさんのSQL本。ミックさんの本も系統は似ていて、DBアーキテクチャというよりも、「SQL」を学ぶための本。Webシステム系の人というよりも業務よりの人の方が向いているかもしれません。
  • その他
    • データベース・リファクタリング
      • 若干粒度が細かいといえば細かいのですが、類書はなく一回読んでおいて損はないです。DBエンジニアの人にとっては当たり前なことも多いかもしれないんですが、AP開発者の人がDB設計を改善する際には役に立つと思います。
System Administration

以下の本は、純粋な運用に関する話ではなく、死活監視、測定、配備といった最近のDevOpsに求められる分野を網羅的にまとめている良書です。DevOpsの人だけでなく、AP開発者の人もAPを作る上で運用が可能なアプリケーションとはどのようなものなのかを意識するのにも役立つのではないかと思います。運用も含めた全体のシステムデザインが、昨今の大規模なクラスタではとても重要です。特に、クラウドインフラが増えていき少数のエンジニアがその上でアプリケーションを開発するようになっていく時代には、AP開発者であってもインフラの基礎知識を持っておくことが今後より重要になっていくでしょう。

Software Engineering系のおすすめ本

Agile

Agileの本は色々でていますが、基本的にはMike CohnとJames O. Coplienの本を読んでおけば大体間違いないです。
僕の場合は、Scrumをベースにした開発プロセスで大体のプロジェクトは進めています。

人間系
  • ワインバーグの本一式。
    • 人への深い洞察は、今読んでも得られるものが多いです。デマルコの本などもよいですが、ワインバーグシリーズが個人的には好きです。

# Amazonへのリンクが欲しいというコメントがありましたので、リンクを追加しておきました。和書が出ているものは、和書のほうにリンクを張りました。

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界隈ではあまり充実していないため、少し作ってみました。是非活用していただければ。

Perl::Metrics::LiteのCLIでPerlモジュールのメトリクス測定

Perl::Metrics::LiteにCLIを追加しました。FIleとSubroutineのメトリクスを測定できます。簡単にlocやmccableのcomplexityなどを測定できるので、casualに使ってみて頂ければ。

また、Jenkins用に組み込むためのmeasureperl-jenkinsというスクリプトも同梱したので使ってみてください。

CLIでのメトリクス測定

基本的な使い方としてはは、Perlのモジュールの入ったlibディレクトリを指定して使います。

measureperl lib

Metricsの閾値を超えた物だけを表示したい場合は、

measureperl -e lib

として実行します。
閾値のデフォルト値は、slocが60、mccable complexityが10になっています。あまり厳しすぎない程度の値なので、デフォルト値のままで使ってもよいんじゃないかなと思います。

以下は、Perl::Metrics::Liteモジュールの測定結果です。

次のように閾値も変更可能ですので、プロジェクトでの許容範囲にあわせて閾値をっ設定してみてください。

bin/measureperl -e -l 30 -c 6 lib

Jenkinsへの組み込み

CheckStyleに変換するためのReportクラスもあるので、以下のような形でJenkinsには、以下のようにcheckstyleの結果を出力することで統合が可能です。先日のJenkinsへのCheckStyleへの統合を、汎用なツールにしてみました。エラーで引っかかった行数のジャンプもできるようにしてあります ;)

measureperl-checkstyle --max_sub_lines 60 --max_sub_mccabe_complexity 10 --directory lib > checkstyle-result.xml

以下でインストールできるので、試してみてください。

cpanm Perl::Metrics::Lite

Enjoy measuring!