Software Engineerにお勧めの技術書
人に聞かれることも増えてきた昨今ですが、お勧めする本は毎年そう変わりはしないのでまとめてみました。言語に依存する本は、書き出すと多くなってしまうので除いてます。
コンピュータサイエンス関連のおすすめ本
Computer Architecture
大規模なシステムを組む場合、高い性能を要求される場合、省リソースが求められるケースなどは、特に低レイヤへの理解の必要性を実感することになります。
下のレイヤを深く理解しておかなければ、このようなシステムのアーキテクチャデザインやトラブルシューティングは実質できません。
- Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く
- Write Great Code〈Vol.2〉低いレベルで考え高いレベルで書く
- パタヘネ本を大学の時に読んでいたときには、その有り難みを半分程度しか理解していませんでしたが、このような本と一緒に合わせて読めていたら、もっと理解がしやすかったのにと思います。翻訳も素晴らしく全てのSoftware Engineerにお勧めしたい良書です。
- コンピュータアーキテクチャ 定量的アプローチ
- Scalabilityを求められるアプリケーションのアーキテクチャを検討するために、Computer Architectureを知っていることが如何に大事かというのを理解できるようになります。Architecture Designを定量的に行うために、このような本と最新のハードウェアの性能測定に基づいて大体の理論値を計算できるようになっておくこととても重要です。
- コンピュータの構成と設計 第4版(上) ハードウエアとソフトウエアのインタフェース (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)
- パタヘネ本。定番ですが読んでおいて損はありません。Write Great Codeと一緒に読むのがよいです。
- プロセッサを支える技術 −−果てしなくスピードを追求する世界 (WEB+DB PRESS plus)
-
- 最新のプロセッサのアーキテクチャがどのようになっているのかを丁寧に解説しており、最近のプロセッサの全体像を把握するのに役立ちます。
OS/Linux Kernel
- The Linux Programming Interface: A Linux and Unix System Programming Handbook
- 詳解UNIXプログラミングの現代版ともいえる本です。まだ読み切れてませんが、非常に細かいところまで書いてあるので、レファレンスとして使っていこうと思っています。ちなみにebookで買わないと色々と大変です。
- Linux Kernel Development (Developer's Library)
- Kernel開発を本格的にするための本というよりも、最近のKernelの概要をコンパクトにまとめてある本です。DBエンジニアやDevOpsの人などが読むのに非常に適した本だと思います。
- Modern Operating Systems
Algorithm/Data Structure
- アルゴリズムデザイン
- 珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造
- アルゴリズムとデータ構造が如何に大事かを様々なエレガントな解決策で提示してくれる本です
設計関連のおすすめ本
Software Architecture
- エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)
- 言わずと知れたMartin Fowlerの良書。
- .NETエンタープライズWebアプリケーション開発技術大全〈Vol.5〉トランザクション設計編 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ―Microsoft.net)
- トランザクション設計に関してこれ以上よくまとまっている本はないです。
- Transaction Processing: Concepts and Techniquesと合わせて読むのがおすすめです。
- Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))
- MQを使ったシステムのデザイン向けで他に類書があまりありません。MQ使われる方にはおすすめです。
- Distributed Systems: Principles and Paradigms
- 分散システムのアーキテクチャに関して幅広く書かれており、分散システムをデザインする人は必ず読んでおいたほうがよい教科書的な本。
- UNIXという考え方―その設計思想と哲学
と合わせて読みたい。Architectureという分類に入れるべきかは微妙なところもありますが...
Software Architectureを考える上で、Computer ArchitectureやArchitecture Patternだけではないというのは、企業で物作りをしている方は感じることがあると思います。以下の本は、Software Architectureをどのような視点で評価するのかということに対して、大局観を与えてくれるものです。
- Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
- Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering)
- Software Architectureをどのような切り口で文書化したらよいのかについての指針を与えてくれる本。設計の文書化をする際に、設計の「思想」をまとめるにも、どのような切り口で書くべきかというのは常に悩ましいところはありますが、この本はそれに大してある一定の切り口を提示してくれている点で貴重です。
Design Pattern
GoFのパターン本以外にも読んでおくべきパターン本はあり、特にConcurrencyに関連する以下の本はおすすめです。
- Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems (Addison-Wesley Object Technology Series)
- Lockに関するパターンなど、余り他の本には書かれていないパターンが書かれている良書。
- Concurrent Programming in Java™: Design Principles and Pattern (Java Series)
/ 増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
/ Java並行処理プログラミング ―その「基盤」と「最新API」を究める―
- Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems
- 複雑な状態遷移をモデリングする際に役立つパターンがちらほらと。
Testabilityの高いDesignをするための本
Robert C MartinシリーズとMartin Fowlerシリーズを読んでおくのがおすすめです。
- レガシーコード改善ガイド (Object Oriented SELECTION)
- Dependencyの切り離し方のPatternのまとめが秀逸。過去の本をよく研究して作られており、コード例も比較的実践的な内容が多いため、あーこれはよくあるよねと納得しながら読むことができる。
- とても良くまとまっており、伊達にRobert C. Martinシリーズとして出版されていないなあといった本。
- Clean Code アジャイルソフトウェア達人の技
, 実装パターン
-
- CodingのIdiom系。1冊は読んでおくとよいと思います
- リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
- 言わずと知れた名著。GoF本と同様に、パターン集的な側面が強いので、Refactoring to Patternsなどと一緒に読むと飽きずに読めると思います。
OOA/D
- アジャイルソフトウェア開発の奥義
- OODの原理原則が秀逸。Bob Martinの本と言えばこれ。Working Effectively with Legacy Codeを含め、多くの本に影響を与えているBob Martinの本。
- エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 現実と乖離するところが多いと言われることのあるこの本ではありますが、当時OO厨な人は誰もが読んでいたこの本。1回は読んでおいて損はないと思います。
Developer Testing
- xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
- 若干内容が重複していて冗長なところはありますが、これ以上にテストのボキャブラリが充実したパターン本は無く、一読の価値はあります。
- Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))
- The Art of Unit Testing: With Examples in .net
- 上記の2冊はTDD本よりは例が実戦的で、新しく読むならTDD本よりこの本がよいかもしれません。TDD関連の本を幾つか読んでいればpassしてよいとは思います。
System Design (Scalability)
Scalabilityという切り口でまとめるのがよいか微妙なところもありますが、Web系システムのScalabilityに関しては、
以下の本がおすすめです。
- Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
- Googleの論文を丁寧に解説してある本で、当初読んだ時は感動しました。ある種の分散システムのデザインの指針となる良書だと思います。
- [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)
- タイトル通りですが、はてなの本で、広範囲にスケーラビリティに関連する話が書かれており、最初に読む本としては最適だと思います。
- スケーラブルWebサイト
- ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
- Front向けの性能チューニングで考えることがよくまとまっている。続編も合わせて読むのがよいです。
- Linuxで作るアドバンストシステム構築ガイド (18Network Server Construction Guide)
- Availability+Scalabilityに関するOSSの設定に関して非常に詳細に記述してあり、実践的で秀逸。
- オンラインゲームを支える技術 −−壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)
Webシステムのデザインであれば、上記の本を読むのでも十分得られることはあると思います。
この分野は類書は数多くありますが、幾つか上記の本を読んだら、分散システム, OS, Database関連の本やHPCの分野の論文などを良く読んだほうがよいです。
DB Design
データベースは、システム開発をする上では避けて通ることのできない分野です。DBはOSとStorageに強く依存しているため、DBのArchitectureだけでなく、ストレージ/OSのアーキテクチャも良く理解しておく必要があります。
- Database Architecture
- データベースパフォーマンスアップの教科書 基本原理編
- DBのArchitecture一般についての理論的背景について非常によく書いてある本。この本は、各DB固有のアーキテクチャの本を読む前に読んでおくのがとてもよいです。
- Expert Oracle Database Architecture: Oracle Database 9i, 10g, and 11g Techniques and Solutions
- プロとしてのOracle物理設計入門 増補改訂版 [Oracle現場主義]
- 実践ハイパフォーマンスMySQL 第2版
- Linux-DB システム構築/運用入門 (DB Magazine SELECTION)
- ストレージサブシステムとDBとの関係についてわかりやすく書いてある松信さんのMySQL本。松信さんの話は、この本だけでなく、その他のプレゼン全般でも、非常にストレージサブシステムへの説明が詳しくおすすめです。
- エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド
- データベースパフォーマンスアップの教科書 基本原理編
データモデリングは、OOA/D と同じくかなり癖のある分野で、これがベストであるといいきれる本はないのですが、以下の本は総じておすすめではないかと思います。ある程度読んだら、キーとなるドメインの知識獲得のほうを大事にしたほうがよいです。
- データモデリング
- T字形ER データベース設計技法
- Entityをコードで認識したり、EntityをEventとResourceに分離したりなど、モデリング手法として勉強になるところはかなりありました。
- Data Modeling Essentials, Third Edition (The Morgan Kaufmann Series in Data Management Systems)
- アート・オブ・SQL ―パフォーマンスを引き出すSQLプログラミング手法
- 色々書いてありますが、モデリング部分は面白いです。
- 独習データベース設計
- 概念モデリング、論理設計、物理設計までの流れが非常にコンパクトにまとまっており、プロセスを学ぶという点では無駄の無い本。
- T字形ER データベース設計技法
- SQL
/達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
- その他
- データベース・リファクタリング
- 若干粒度が細かいといえば細かいのですが、類書はなく一回読んでおいて損はないです。DBエンジニアの人にとっては当たり前なことも多いかもしれないんですが、AP開発者の人がDB設計を改善する際には役に立つと思います。
- データベース・リファクタリング
System Administration
以下の本は、純粋な運用に関する話ではなく、死活監視、測定、配備といった最近のDevOpsに求められる分野を網羅的にまとめている良書です。DevOpsの人だけでなく、AP開発者の人もAPを作る上で運用が可能なアプリケーションとはどのようなものなのかを意識するのにも役立つのではないかと思います。運用も含めた全体のシステムデザインが、昨今の大規模なクラスタではとても重要です。特に、クラウドインフラが増えていき少数のエンジニアがその上でアプリケーションを開発するようになっていく時代には、AP開発者であってもインフラの基礎知識を持っておくことが今後より重要になっていくでしょう。
Software Engineering系のおすすめ本
Agile
Agileの本は色々でていますが、基本的にはMike CohnとJames O. Coplienの本を読んでおけば大体間違いないです。
僕の場合は、Scrumをベースにした開発プロセスで大体のプロジェクトは進めています。
- Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))
- User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))
- Agile Estimating and Planning (Robert C. Martin Series)
- Lean Architecture: for Agile Software Development
- アジャイルサムライ−達人開発者への道−
- 後発だけあってよくまとまってます。今からならこれから読むとよいかもしれません。
kamakura
id:vkgtaro さんと鎌倉いってきたときの写真。由比ケ浜は夕焼けが絵になって素晴らしかったですね。また行きたいなあ。
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!
3分でPerlのプロジェクトをJenkins Readyにする
こんばんは、着る毛布が届く前に風邪を引いたdannです。
色々な環境やプロジェクトに携わっていて、その度にJenkinsのセットアップやPerlプロジェクト用のモジュールのインストールなどをしていたりしませんか。また、プロジェクトを作るたびに、Job毎にプラグインの設定などを繰り返していたりしませんか?
これらの設定は、完全に自動化することが可能です。Jenkinsのように良く使うツールは、これらのセットアップも自動化していくと捗ります。以下では、その方法を説明します。
以下に、Jenkinsプロジェクトの開始に必要なテンプレートを用意したので、参考にしてみてください。以下では、以下のtemplateを使ったセットアップ方法について説明します。
https://github.com/dann/perl-jenkins-template
Jenkinsのプロジェクトに必要なPluginのセットアップの自動化
Jenkinsでは、GUIだけでなく、jenkins-cliを使うことでCUIでインストールすることができます。
これを使って以下のようなスクリプトで、JenkinsのPluginとJenkinsの統合に必要なPerlのモジュールをインストールします。
これによって、プロジェクトに必要なプラグインやPerlのモジュールは自動でインストールできます。
https://github.com/dann/perl-jenkins-template/blob/master/setup_jenkins_modules.sh
#!/bin/bash #================================== # Configuration #================================== HOSTNAME=localhost PORT=8080 #================================== # Main #================================== JENKINS_PLUGINS=( git checkstyle htmlpublisher clover plot ) PERL_MODULES=( Devel::Cover Devel::Cover::Report::Clover Perl::Metrics::Lite https://github.com/dann/tap-to-junit-xml/tarball/master ) setup() { fetch_jenkins_cli install_jenkins_plugins install_jenkins_related_perl_modules restart_jenkins clean_jenkins_cli } fetch_jenkins_cli() { curl -LO http://${HOSTNAME}:${PORT}/jnlpJars/jenkins-cli.jar } jenkins_cli() { java -jar jenkins-cli.jar -s http://${HOSTNAME}:${PORT} $@ } install_jenkins_plugins() { for plugin in ${JENKINS_PLUGINS[@]} do jenkins_cli install-plugin ${plugin} done } install_jenkins_related_perl_modules() { for module in ${PERL_MODULES[@]} do cpanm $module done } restart_jenkins() { jenkins_cli safe-restart } clean_jenkins_cli() { rm jenkins-cli.jar } setup
Jenkinsのproject-templateを用意しておくと捗るぞ
概要
多くののLLのプロジェクトの場合は、シェルのステップを設定しているか、実行するためのbuild.xmlを用意しておいて、ビルドのステップのセットアップをして使っているかなんじゃないかと思います。こういったプロジェクトのステップの設定やどのプラグインを使うか、プラグインの設定など、そういったプロジェクトの設定を手動でするのって面倒ですよね。
要するに既存Job設定をコピーすることで、既存の設定を使い回せる機能があるので、それを使うということですね。
これによって、Clover用のプラグインでディレクトリでcover_dbのディレクトリを指定したり、Devel CoverのHTMLの結果をHTML Publisherなどでpublishするディレクトリを指定したり、Publish Checkstyle analysis resultsなどの実行するプラグインをチェックしたりといったのを手動ですること無く、自動で設定された状態にすることが可能になります。
Job Templateのインストールの仕方
以下の定義が実際のjobのテンプレートになります。以下に、上記のビルドステップのスクリプトとプロジェクトで必要となるプラグインの設定が有効になるjobテンプレートを用意しておきました。Job定義はXMLでJenkinsのHomeディレクトリ(ex /var/lib/jenkins)以下のjobsディレクトリに保存されているので、既存Jobでよく使う部分はテンプレートのXMLとして定義して保存しておきます。
https://github.com/dann/perl-jenkins-template/blob/master/config.xml
上記のテンプレートを自動インストールするスクリプトは、以下になります。Configセクションの変数を各自の環境にあわせて使ってみてください。
https://github.com/dann/perl-jenkins-template/blob/master/setup_jenkins_job_template.sh
Jobテンプレートの適用になり有効になるもの
上記のJob templateをインストールすると、以下のものがデフォルトで有効になります。
- JUnitとの統合によるテスト実行結果
- Cloverの統合によるテストカバレッジの可視化
- Devel::CoverのHTMLレポート
- Perl::Metrics::LiteによるCheckStyleとの統合
このJob Templateによって、プラグインだと次のようにCheckStyle, Clover, JUnitなどのプラグインの設定がされます。
また、ステップについては、以下のような設定が自動設定されます。
set -ex #=============================================== # Configuration #=============================================== export PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:${PATH}" export LOG_DIR=$WORKSPACE/logs export PERL5LIB="$WORKSPACE/lib:$WORKSPACE/t/lib:$WORKSPACE/t/*/lib:${PERL5LIB}" export PERL_TEST_HARNET_DUMP_TAP=$LOG_DIR export TEST_VERBOSE=1 #=============================================== # Main #=============================================== clean() { [ -f Makefile ] && make -k realclean rm -rf Makefile Makfile.old MANIFEST blib *.tar.gz rm -rf $LOG_DIR cover -delete } setup() { perl Makefile.PL mkdir -p $LOG_DIR } do_test() { HARNESS_PERL_SWITCHES=-MDevel::Cover=+ignore,inc prove -lv t 2>&1 | tee -a $LOG_DIR/tests.tap } convert_to_junit_xml() { tap-to-junit-xml --input=$LOG_DIR/tests.tap --output=$LOG_DIR/tests.xml } make_coverage() { cover -report clover cover } measure_metrics() { measureperl-checkstyle --max_sub_lines 60 --max_sub_mccabe_complexity 10 --directory lib > checkstyle-result.xml } main() { clean setup do_test convert_to_junit_xml make_coverage measure_metrics } main
まとめ
まとめると、
- JenkinsのPluginやプロジェクトに必要なモジュールのインストールを自動化しておくと捗るぞ
- JenkinsのJobでプロジェクトに共通な設定は、あらかじめJob定義のXMLをテンプレートを用意しておき、Copy existing Jobでコピーすると設定を使い回せて捗るぞ
ということになります。
使うプラグインや設定など、プロジェクトによって異なる点もあると思いますが、このようなベースを用意しておくことで、いわゆる定型作業を減らすことができ、プロジェクト間でのばらつきを抑えることが可能になります。是非、このようなテンプレートをベースにして、各自のプロジェクトに合わせたJenkinsのJobテンプレートを作ってもらえたらなと思います。
これらは、Perlのプロジェクトだけで使える話ではなく、他の言語でも使える話ですので、是非自動化して、プロジェクトレベルでの標準化と自動化を進めてみてください。
Enjoy automating!
Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール - Perl Advent Calendar 2011
Perl Advent Calendar Hacker Trackの21日目です。
http://perl-users.jp/articles/advent-calendar/2011/hacker/21
こんばんは。dann です。みなさん、意識は高まっていますか? 僕は上々です。
今回は拙作の Perl::Metrics::Lite というモジュールを紹介させて頂きます。
開発した動機
Perl::MetricsやPerl::Metrics::Simpleなど、PerlのコードのMetricsを測定するツールがあるのですが、どれも使い勝手の点でいまいちです。
Perl::Metricsは測定項目をプラガブルに追加可能なのですが、APIがプリミティブすぎてMetricsを測定するには使いずらいです。
一方、Perl::Metrics::Simpleは、Perl::MetricsをよりユーザーフレンドリなAPIにして、名前の通りシンプルに使えるように作られているのですが、今度は測定項目が拡張可能になっておらず、特定のメトリックしか測定できませんでした。
Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール
従来のモジュールの問題点を解決するために、Perl::Metrics::SimpleとPerl::Metricsのいいとこどりをして、測定項目をプラガブルに追加できるPerl::Metrics::Simpleのような使い勝手のいいモジュールを作ってみました。
http://github.com/dann/p5-perl-metrics-lite
使い方はPerl::Metrics::Simpleと殆ど同じで、以下のように使います。
use Perl::Metrics::Lite; my $analzyer = Perl::Metrics::Lite->new; my $analysis = $analzyer->analyze_files(@ARGV); my $file_stats = $analysis->file_stats; my $sub_stats = $analysis->sub_stats;
egディレクトリに実行可能な簡単なサンプルをいれてあるので、
是非実行して確認してみてください。
https://github.com/dann/p5-perl-metrics-lite/blob/master/eg/measureperl
測定項目の拡張方法
以下に幾つかFileとSubroutineのMetricsの測定のPluginのサンプルをいれています。
initとmeasureメソッドを実装する必要があります。measureメソッドのfileまたはsubroutineのPPI::Documentを操作して、必要なMetricsの計算を行います。
まとめ
Perl::Metrics::Liteにより、簡単にFileとSubroutineのMetricsを拡張して、測定項目を追加していくことが可能になりました。是非色々なMetricsの測定をしてみてください。
Enjoy measuring!