ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション

著者 : ThoughtWorks Inc. 株式会社オージス総研オブジェクトの広場編集部

• オライリージャパン (2008年12月27日発売)

作品紹介・あらすじ

マーティン・ファウラーが所属することでも知られるThoughtWorks社は、アジャイルコミュニティへの貢献で世界に知られています。本書は14人のThoughtWorkerが綴ったエッセイ集です。DSL、プログラミング言語、多言語プログラミング、オブジェクト指向設計、マネージメント、メトリクス、SOA、ドメインアノテーション、ビルド、デプロイ、テストといった、ソフトウェアのライフサイクル全般にわたる広範囲かつ興味深いテーマが目白押しです。ThoughtWorkerの知見に触れることができる一冊です。

感想・レビュー・書評

[minさんの感想 · 2019年5月27日]

ThoughtWorks社で働くThoughtWorker数名のエッセイ集

オブジェクト指向エクササイズが特に面白かった
良いオブジェクト指向のコーディングを突き詰めるとこれだけシンプルな形で実装ができるという良い例だった

[Kōhei Yamamotoさんの感想 · 2016年9月19日]

オブジェクト指向エクササイズ目当てで読んだ。Ruby によるいろいろな方法での DSL 実現もおもしろい。後半は流し読み……

[miturumaさんの感想 · 2023年11月22日]

自分の興味のある範囲が「5章 オブジェクト指向エクササイズ」、自分の経験のある範囲が「10章 Ant ビルドファイルのリファクタリング」で、この内容だけで読んだ甲斐はあったと思う

[khappyさんの感想 · 2014年4月2日]

むづかしい…
Rubyを勉強してから読もうっと。

[naotawoolさんの感想 · 2013年5月29日]

やっぱり「オブジェクト指向エクササイズ」の章は為になった。今までは、エクササイズの内容しか知らなかったから、その理由も分かって良かった。

[Mayさんの感想 · 2013年4月4日]

なかなかハードなプログラミング・エッセイ。
この手のジャンルはなかなか奥深く、気楽に読めるものから、「やっぱりこうしないとダメだよな」と猛省を促すものまで、あらゆるタイプのものがありますが、本書は後者の系統。
後半に進むにつれて、個人的にはとても馴染み深い問題へとつながってゆく。すなわち、開発、ビルド、試験。アジャイルの肝とも言える、CIと関連付けられた自動テスト。

「オブジェクト指向エクササイズ」「アジャイルかウォーターフォールか」の2エッセイを読めただけでも価値がありました。
この手のプログラミングエッセイでは「でも、実際は違うんだよな...」とため息をつかざるを得ない場面がよくあるが、今なら、本当にすぐに試してみようと思える。これは個人的意見だが、実際に、ウォーターフォールに振り回されて「結果アジャイルのウォーターフォール体制」に放り込まれた身からすれば、ねえ...

[starzeroさんの感想 · 2012年10月7日]

前半は理解できなかい箇所が多かったが、後半のテストについてあたりは面白かった。
オブジェクト指向エクササイズはいつか実践してみたい。

[akiyama924さんの感想 · 2012年5月1日]

ThoughtWorksは、日本で言えば、豆蔵のような会社だそうです（推薦の言葉で、羽生田栄一氏が書いているので間違いありません）。

つまり、この本は、羽生田さんや、萩本さんや、大西さんや、湯本さんが書いたエッセイという感じと思っていただければ遠からずというところです。

さて、内容ですが、

1 章 ビジネスソフトウェアの「ラストマイル」を解決する
2 章 とある秘密基地とRuby による20 のDSL
3 章 言語の緑豊かな景観
4 章 多言語プログラミング
5 章 オブジェクト指向エクササイズ
6 章 ところでイテレーションマネージャとは何だろうか
7 章 プロジェクトバイタルサイン
8 章 コンシューマ駆動契約――サービス進化パターン
9 章 ドメインアノテーション
10 章 Ant ビルドファイルのリファクタリング
11 章 1 クリックデプロイ
12 章 アジャイルかウォーターフォールか――エンタープライズWeb アプリケーションのテスト
13 章 実践的な性能テスト

と多岐に渡っています（12章と13章はテストの話題です）。

私は、

3 章 言語の緑豊かな景観
5 章 オブジェクト指向エクササイズ
12 章 アジャイルかウォーターフォールか

がおもしろかったです（さっぱり分からなかったのは、2章のDSL、8章のコンシューマ駆動契約、10章のAntです）。

★

3章の「言語の緑豊かな景観」では、

X = y/0;
Y = 6;
End(Y);

というおかしなプログラムがあったときに、遅延評価をするHaskellのような言語では、エラーにならず6を返す（何故なら、結果を得るためにXの値を決定する必要がないためX=y/0;の文は無視されるから）という話がおもしろかったです。

遅延評価をする言語のテストって難しいかもと思いました。

★

5章の「オブジェクト指向エクササイズ」では、「ソフトウエア設計を改善する9つのステップ」として、

1. 1つのメソッドにつきインデントは1段階までにすること
2. else句を使用しないこと
3. すべてのプリミティブ型と文字列型をラップすること
4. 1行につきドットは1つまでにすること
5. 名前を省略しないこと
6. 全てのエンティティを小さくすること
7. 1つのクラスにつきインスタンス変数は2つまでにすること
8. ファーストクラスコレクションを使用すること
9. Getter、Setter、プロパティを使用しないこと

を挙げているのがおもしろかったです。

筆者の提案は、この9つのルール（縛り）を設けて、20時間かけて、1,000行のコードを書くという訓練をしなさいということで、それによって、カプセル化、ポリモフィズム、命名戦略の意義が体感できるのでいいよ！という話です。

これはいい！と思いました。

★

テスト関係で、「はっ」と思ったのは、

　　探索的テストの終了基準
　　　　テストアナリストから、アプリケーションの品質がよいという信頼を得る

　　探索的テストは、アジャイルなプロジェクトにとっては重大なテストフェーズです。

　　不具合管理はアジャイルなプロジェクトでも適用できます。開発中のストーリーで不具合が発見されたときは、インフォーマルな（肩越しの）コミュニケーションによって開発者たちにこれらの不具合が伝えられて、その不具合は即座に修正されます。現在のイテレーションのストーリーに関係しない不具合や、開発中のストーリー内での重要でない不具合が発見されれば、その不具合は不具合追跡ツールに登録されます。不具合はその後、ストーリーと同様に扱われます。つまり、ストーリーカードが作成され、顧客によって優先度をつけられ、ストーリーのバックログに追加されます。

不具合管理を課題管理という位置づけで考えると、重要なバグは即座に直して管理せず、それ以外のバグを顧客と話し合いながら要求を管理するように取り扱うという方法もあるのだなぁと考えさせられました。

ということで、個性的なエッセイが多く、おもしろい本でした。おすすめです。

[tnumata3632さんの感想 · 2012年2月5日]

章ごとのエッセイ。前半は難しいものが多かった。後半の「1クリックデプロイ」等が面白かった。また読む

[isseiumさんの感想 · 2011年4月28日]

とても興味深いテーマが多かった。理解出来なかったテーマもあるけれど、それは自分の技術力がまだ追いついていない or 実体験がないからかなとも思った。時間をあけてまた読んでみたいと思う。

特に印象深かったのは次のとおり

・第3章 言語の緑豊かな景観
様々な言語の特徴について語られていておもしろい。いろんなパラダイムの言語を触りたくなった

・第5章 オブジェクト指向エクササイズ
オブジェクト指向プログラミング時における、気をつけるべきルールが具体的に9つあげられていた。なかなか難しいが、次の開発のときは気にしてみたい。

・第12章 アジャイルかウォータフォールか
業務でちょうどテストについて悩んでいたのでとても助かりました。
テストの種類、テストの環境について、アジャイルの場合とウォータフォールの場合を比較して解説していただいた。


あと、訳者あとがきにあった、日本の現場はまだ「開発」の部分での問題を大きな関心事にしているが、これは数々のアジャイルプラクティスですでに解決できている、という旨が気になった。2008年時点でこう言われているが、2011年のいま現場はどう変わったのか。