Hudson+phpmdでPHPコードの問題を自動検出する方法
Hudson＋PHPシリーズです（Javaとか他の言語でもいけるはずです）。
phpmdって何？
phpmdはPHP Mess Ditectorの略で、PHPコードの潜在的なバグになりそうな箇所や実装上の問題を検出してくれるツールです。 例えば未使用の変数の指摘、多数のpublicメソッドのある巨大クラスの検出、一文字変数等もこのツールで検出可能です。
詳細はhttp://phpmd.org/about.htmlを参照してください。
phpmdのインストール
これは簡単で、いつものようにpearコマンドでさくっと入ります
pear channel-discover pear.pdepend.org
pear install --alldeps pdepend/PHP_Depend-beta
pear channel-discover pear.phpmd.org
pear channel-discover pear.pdepend.org
pear install --alldeps phpmd/PHP_PMD-alphaなお動作させるにはPHP5.2.3以上が必要となります（ので生のCentOSとかだとPHPのバージョンアップが必要）。
phpmdの使い方
まずコマンドラインでの使い方は以下のようになります。
Mandatory arguments:
1) A php source code filename or directory
2) A report format
3) A ruleset filename or a comma-separated string of rulesetfilenames
Optional arguments that may be put after the mandatory arguments:
--minimumpriority: rule priority threshold; rules with lower priority than this will not be used
--reportfile: send report output to a file; default to STDOUT
--suffixes: comma-separated string of valid source code filename extensions
--exclude: comma-separated string of patterns that are used to ignore directoriesそれぞれの引数は以下のとおりです。
- 第1引数が解析対象のphpファイルまたはディレクトリ
- 第2引数が出力レポートの形式(text, xml, html)
- 第3引数が適用するルールセットのファイル名か、カンマ区切りで列挙したルール(codesize,unusedcode,naming,design)
ルールについてはhttp://phpmd.org/rules/index.htmlを参照してください。
Hudsonで自動的にやらせる
Hudsonの管理画面からPMDプラグインを導入する
インストールしたらHudsonを再起動します。
build.xmlを用意する
<target name="phpmd">
<exec command="phpmd /path/to/source/ xml codesize,unusedcode,naming,design \
--reportfile /path/to/reports/pmd.xml \
--exclude /path/to/source/tests
" />
</target>それぞれが何を意味しているかはコマンドラインオプションのところを参照してください。
プロジェクト側の設定
ビルドの設定で上記xmlで新たに作成したターゲットを指定します。 （phingを使うことを前提にしているので、こちらを参照してphingの設定はしてください）
プロジェクトの設定画面を開き、PMD警告の集計にチェックを入れ、レポートのパスを指定します。
これで準備完了です！
これで準備が完了したのでビルドします。 ビルドすると、プロジェクトページにPMD警告の推移がグラフ表示されるとともに、詳細の警告内容が確認できるはずです。
最後に
こういうツール系は思いついたときに動かすのではなくて、プロジェクト期間中ずっと継続的に動作させておく必要があります。 そして検出した内容は将来に技術的負債を残さないためにも、随時修正していけば良いでしょう。 ただし全部修正する必要があるかどうかはよく考えるべきです。 あくまでリスクが高そうな箇所を検出してくれているので、検出結果を見ながらプロジェクトの内容にあわせて判断する必要があります。 むやみやたらに全部対応するのはROIは高くありません。
なお、随時コードを修正していくためには、「自動化されたテスト」が必要であることは言うまでもありません。 テストでガードされていないコードをどんどん直すのは自殺行為に近いとも言えます。 リファクタリングは前提としてテストの自動化があることは忘れてはいけません。
![サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ]](/images/common/book_devops.png)
