ThoughtWorksアンソロジー

読書 技術

ThoughtWorksアンソロジー —アジャイルとオブジェクト指向によるソフトウェアイノベーションThoughtWorksアンソロジー —アジャイルとオブジェクト指向によるソフトウェアイノベーション
株式会社オージス総研 オブジェクトの広場編集部

オライリージャパン 2008-12-27
売り上げランキング : 3072

Amazonで詳しく見る by G-Tools

アジャイル開発の分野で名をはせるThoughtWorks社のメンバーによるエッセイ集。

エッセイ集ということなので、頭から読む必要はなく、興味のあるトピックを拾い読みすればよいかと。

個人的に興味深かったのは、次のもの。

２章 とある秘密基地とRubyによる20のDSL

Martin Fowlerによる、内部DSLのHowto。退屈で複雑でかっこわるいオブジェクト生成定義が、どんどん洗練されていき、内部DSL化されていく様が面白い。俺みたいなRuby厨は素直にRubyすげぇ、と思わせられる記事。他の言語だとこうシンプルにはできまい。やはりイテレータ（クロージャ）が有用すぎる。他の言語でも似たようなことはできるが、似たようなことしかできない。

この記事でもinstance_evalを使ってクロージャからレシーバを除去するという、知らない人が見ると魔法に見えるテクニックが簡単に説明されているが、コンテキストがころころ変わるので利用者が混乱しやすい（特にself使いたいときとか）というリスクにもちゃんと触れてある。俺も素直にレシーバ書いて使う方がシンプルに感じるな。

４章 多言語プログラミング

Javaの設計者が"言語とプラットフォームの分離"という素晴らしい決断をしてくれたおかげで、単一のプラットフォーム上で複数の言語を使える時代が到来している。だから、これからの開発は特定の言語で全ての問題を解決するのではなく、得意分野の異なるいくつかの言語を併用して、より効率的に問題解決していくのだ、という話。

これ、言ってることは本当によく理解できる。Javaでプログラムを書いていると、テストケースを書くときにJavaという言語が持つ静的言語らしい数々の制約、すなわち"自分の銃で自分の足を撃ち抜かないための工夫"が足を引っ張る。柔軟な動的言語のパワーが欲しい。そんなときに、GroovyやJRubyを使ってテストケースを書けたらどんなに楽かと思う。MockやStubも簡単に作れるし、必要であればJavaの豊富なライブラリだって使える。

ただ、この主張に乗るためには"複数の言語を覚えなければならない"という高い壁があるのが難点。俺みたいに新しい言語を覚えることを楽しめる人種であればよいのだが、一般的なエンジニアはそうじゃないからね。「Javaしかできませんがなにか？」という感じで。そうした人々に「テストケースを書くために新しい言語一つ覚えてくれ」と言ってうなずいてもらえるかというと、自信ない。その気になればJavaの文法をそのまま持ち込めるGroovyならばなんとか、とも思うが、Javaに引きずられすぎていて動的言語としては半端な感じがするので、むしろ学習に手間取る予感も…。いや、あれはあれで好きなんだけど。

５章 オブジェクト指向エクササイズ

手続き型プログラミングの悪習から逃れて、本当の意味でオブジェクト指向的なプログラミングを行うためのエクササイズ。極論とも言えるような、「ほぼ必然的にオブジェクト指向になるコードを書くように強制する」９つのルールが提示されている。例えば「elseを使わない」「メソッドのインデントは１つまで」「Getter, Setter, プロパティは使用しない」など。

まともに守れば、イヤでもクラスやメソッドのサイズは小さくなり、それに伴い責務は分散され、カプセル化が守られ、条件分岐はポリモーフィズムに取って代わる。

このルールを完全に遵守してプログラミングすべき、という話ではない。この極端なルールに従ってプログラミングしていくなかで、学び取れることがありますよ、という提案である。各ルールの間で矛盾が生じたり、ルールに従うことでコードが改悪されることもある。しかし、そうなるということを理解することもまたエクササイズの目的なのである。

１０章 Antビルドファイルのリファクタリング

Antのビルドファイルを書く機会がある人は必読。なんでみんなビルドファイルを書くとなると保守性を捨てて好き放題書き散らすようになるのか。これもソースコードと同様にちゃんとメンテナンスしてやらねばならない。悪いネーミングは排除すべき！一つのターゲットになんでもやらせるべきではない！同一定義の複数記述は悪！

macrodefなどという便利なタスクが追加されていたとは知らなかった。他に、callじゃなくてdepends使え、valueじゃなくてlocation使え、デプロイコードは分離してimportで取り込め、などなど24項目。ビルドファイルを依存関係やネーミングにまつわる混乱、定義の重複による保守性の低下などなどから守るためのテクニックの数々。まさにリファクタリング。Antのビルドファイルはあっという間に肥大化するから、こういうテクニックをちゃんと抑えておかないと、すぐに混沌としてくる。

Mavenを導入するというのも手なのだが、あれは学習コストが高いし、Antほど自由がきかないので、ある程度環境を選ぶ。だから、Antの完全な代替品にはなり得ないと思う。まだまだAntの出番はあるのだ。

１２章 アジャイルかウォーターフォールか……エンタープライズWebアプリケーションのテスト

アジャイルプロセスとウォーターフォールプロセスの比較、という内容なのだが、どちらかというとアジャイルプロセスにおけるテストの実施方法についてのエッセイ。

単体テストは自動化。機能テストも自動化。ユーザ受け入れテストも自動化。非機能テストも自動化。

どんなテストもとにかく自動化し、継続的ビルドに含める。そしてなるべく早く始める（ソフトウェアの完成を待たず、ストーリー単位でテスト）。それに尽きるようだ。

各テストに使えるツールもいくつか紹介してある。やはり機能テストはSeleniumか…。


今回挙げたものはどれも面白いし、他のエッセイも興味深い内容であった。プログラミングべったりな内容ではなくて、プロジェクト運営についての話も多い*1。そのため、プログラマに限らず現場で活躍するIT関係者であればたいていの人は楽しめるのではなかろうか。

*1:特にアジャイルとCI（継続的インテグレーション）についてのエッセイが多かったように思う。