Antリファクタリングカタログ

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本を読んで興味深くかつすぐに使えそうな箇所は「Antビルドファイルのリファクタリング」だった。
以下メモ書き。

【1】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の1章に「ビジネスソフトウェアの「ラストマイル」を解決する」という章がある。
長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。

XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。
しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。
理由は、3つある。
一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は検証の工数が大きすぎるからだ、と。

アジャイル開発の最終目標は「バージョンのないソフトウェア」を提供することにある、と。
つまり、仕様変更の要求が発生したら、それを開発して完成したら、すぐにリリースして本番稼動できることだ、と。

この指摘は、アジャイル開発の別の問題点を示していると思う。
今僕が考えているチケット駆動開発、プロジェクト管理サーバーは、アジャイル開発のプロジェクト管理へ適用して、大幅に改善できると考えている。
上記では、大規模システムへアジャイル開発を適用した場合、開発プロセスの効率化ができたのを前提とした上で、リリース管理に問題があることを指摘している。

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」にも書いているが、上記にあげたリリース管理の問題点は、二つの技術で大幅に改善できると思う。
一つは、ビルド作業やリリース作業の並行化。
いわゆる並行ビルド、並行リリース。
Hudsonなら、並行ビルドも簡単に操作可能。
これによって、二つ目と三つ目の問題が解決できる。

もう一つは、本番環境を仮想化して複数のテスト環境を作って、検証可能にしておくこと。
昨今ならVMWareで仮想イメージを簡単に作ることができる。
これによって、一つ目の問題も解決できる。

実際の現場ではまだ一つのアイデアに過ぎないだろうが、そのアイデアを実現する技術は既に登場していることに注意しよう。

【2】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の10章にAntビルドファイルのリファクタリングが書かれている。
Antビルドファイルのリファクタリングは実施した経験が無かったけれど、さっそく使ってみたい技術の一つ。
Antだけでなく、MavenやRakeなどでもその発想は使えるはずだ。

【元ネタ】
2009-01-05 - yyamanoの日記

【Antリファクタリングカタログ】

【1】ターゲットの抽出
* macrodefの抽出 - コードブロックをmacrodefとして抽出する
* ターゲットの抽出 - 大きなターゲットを小さなターゲットに分割し、依存関係を定義する
* ターゲットのラッパービルドファイルへの移動 - CI用のターゲットは別ビルドファイルに移動する
* デプロイ用コードのimport先への分離 - デプロイ用のコードは別ビルドファイルに移動する
* build.xml内へのラッパースクリプトの取り込み - シェルスクリプトで定義しているパスやオプションをビルドファイルに移動する
* 明確なターゲット名の導入 - ターゲットとプロパティで異なる命名規則を使う
* ターゲット名の名詞への変更 - ターゲット名にはプロセスではなく成果物の名前を使う

【2】コメント取り込み
* descriptionによるコメントの置き換え - XMLコメントのかわりにdescription属性を使う
* taskname属性の追加 - タスクの意図を明確にし、実行状況を簡単に把握できるようにtaskname属性を使う

【3】実行処理
* 内部ターゲットの強制 - 内部ターゲットの先頭にハイフンを追加し、コマンドラインから呼べないようにする
* 出力ディレクトリの親ディレクトリへの移動 - 生成される成果物の出力先を一カ所にまとめる
* applyによるexecの置き換え - execのかわりにapplyを使う
* CI Publisherの利用 - タグ処理は独立したターゲットとして分離する

【4】プロパティや依存関係の共通化
* 宣言の導入 - if条件分岐のかわりに、プロパティとimportを使う。
* 依存によるcallの置き換え - 明示的なantcallのかわりに宣言的な依存関係を使う
* プロパティによるリテラルの置き換え - 頻繁に使うリテラル文字列をプロパティに置き換える
* filtersfileの導入 - filter要素のかわりにプロパティファイルとfiltersfile属性を使う
* プロパティファイルの導入 - プロパティ定義を外部ファイルに移動する
* 要素のantlibへの移動 - 複数のプロジェクトで使われるコードをantlib.xmlに移動し配布する
* filesetによる多数のライブラリ定義の置き換え - pathelement要素のかわりにfileset要素を使う
* 実行時プロパティの移動 - ビルドに使うプロパティと実行時に使うプロパティを分離する
* IDを用いた要素の再利用 - 重複したpathのような要素をidを使い共通化する
* プロパティのターゲット外部への移動 - ターゲット内部で定義されているプロパティをターゲットの外に移動する
* locationによるvalue属性の置き換え - パスを表現するプロパティではvalue属性のかわりにlocation属性を使う

上記のリファクタリングカタログで面白いと思ったのは、コメントをタスクの属性(description, taskname)にしてしまうこと。
もう一つは、ターゲットを処理ではなく成果物の名前にすること。

Antは宣言的であってスクリプト言語ではない特徴がある。
だからこそ、ターゲットは成果物の名前にして、コメントも宣言に取り込んでしまうようだ。

このAntリファクタリングカタログは、ファウラーのリファクタリング本(リファクタリング―プログラムの体質改善テクニック)のように、抽出とインライン化の組み合わせなどもあり、非常に有用だと思う。