「ThoughtWorksアンソロジー」を読んだ

少し古い本ですが、「ThoughtWorksアンソロジー」を読んだので、読書記録を書いていきます。
最初に読んだきっかけを書いた後、章毎に感想を記載していきます。(2日かけて書いたこともあり、やや記事が長めで3500字位あります)

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

本を読んだきっかけ

現在自分たちのチームでは、オブジェクト指向のトレーニングを実施しています。
このトレーニングで、「ThoughtWorksアンソロジー」の第5章「オブジェクト指向エクササイズ」を使用してプログラムを書くということをしているのですが、これがチームで好評となっています。
そのため、開発力を向上させるために有効な実践的な知識が「オブジェクト指向エクササイズ」以外にもあるんじゃないかという仮説を持ち、本を読んでみることにしました。

第1章 : ビジネスソフトウェアの「ラストマイル」を解決する

1章からいきなり刺さる内容でした。
先日自分たちが機能開発を進めた際、機能要求を満たした上で、既存よりも内部品質を上げて本番環境にリリースしようと思ったのですが、リリース直前の社内判定会で性能面の懸念を指摘されてNGを食らい、保守性を大きく犠牲にしてリリースすることになりました...
現行の性能を考慮すると殆ど劣化しないはずですが、理論的に性能影響がないことを説明することができず*1、本番で性能要件を満たせなくなる可能性が僅かでもあるならリリースNG、という話になってしまった形です。
この章を読んで、非機能要求を満たしていることを自動で担保できる仕組みを一刻も早く作りたいと危機感を持ちました。

第2章 : とある秘密基地とRubyによる20のDSL

Martin Fowlerが執筆している章です。
自分はRubyあんまり詳しくないので軽い感想しか書けませんが、クロージャの威力がこれでもか！と強調されていたのが印象的でした。

第3章 : 言語の緑豊かな景観

プログラミング言語の多様性と言語の特徴やカテゴライズが丁寧にされていました。
上記の話を通して筆者が語りたかった、「完全なプログラミング言語はなく、どの言語が優れているかの議論よりも解決したい問題に対してどの言語が適しているかの話をしよう」という主張は、改めて言語に対してあるべき姿勢を確認できてよかったです。*2

第4章 : 多言語プログラミング

第3章と似たような話で、一つの言語に固執してプログラミングしてはいけない、という話でした。
第3章との合わせ技で、やっぱりパラダイムが違う言語をどんどん学んでいかなきゃな...という気持ちになる章でした。

第5章 : オブジェクト指向エクササイズ

自分が本書を読むきっかけにもなった、おさらく本書で最も有名な章です。
Qiitaとかでもたくさん記事書かれているので、リンクだけ貼って詳細は割愛します。

qiita.com

今のチームでは、トレーニングの成果を実戦する場として、調査的リファクタリング*3する時に、コードの見通しを良くするためにこの9つのルールを意識してリファクタリングしていますが、効果を実感できているので、お勧めです。*4
具体的には、後からソースコードリーディングするメンバーのキャッチアップ速度向上, 潜在バグの発見といった効果が9つのルールに従うことで実感できています。

第6章 : ところでイテレーションマネージャとは何だろうか

イテレーションマネージャー、自分は初耳の言葉でした。
チームのボトルネックを可視化することや、チームが優先度の高い開発をすることだけに集中できるように支援する、ということから、スクラムマスター要素が強いのかな、と思いましたが、何が顧客にとって最優先の機能かを考え、時には顧客の要求をヒアリングして顧客の代弁者としての役割も担う、という話もあったので、プロダクトオーナーとしての責任も兼務しているのかな、と思いました。

第7章 : プロジェクトバイタルサイン

プロジェクトやチームが機能しているか複数の指標を集めようという話でした。
目新しい指標というのはありませんでしたが、指標を収集することの重要性が確認できた点と、「チーム知覚」の指標のように個人の感覚を定量的な指標に落とすことの重要性を実感できた点の2点について、学びがあった章でした。

第8章 : コンシューマ駆動契約

マイクロサービスアーキテクチャの文脈で出てくるコンシューマ駆動契約が、この時代(本書が発表されたのは2008年)に書かれていた本で出てきたことに驚きました。
プロバイダ契約, コンシューマ契約, コンシューマ駆動契約の説明と、それぞれの契約の動機、メリット、課題が丁寧に書かれていて、あまりマイクロサービスアーキテクチャに触れたことのない自分でも、適用することで効果が出るシチュエーションのイメージがついたので、良かったです。

第9章 : ドメインアノテーション

第9章に限った話ではないが、ポエムではなく実践的な内容で面白かったです。
ただ、「ドメインモデル内のメタデータにはアノテーションを付与しよう、アノテーションを付与することでドメインモデルとインフラコードを分離して再利用性を高めよう」という思想は納得感があったものの、今の現場で本書に記載されているメリットを享受できるような形でアノテーションを適用するイメージは中々湧かない...というのが正直な感想でした。

第10章 : Antビルドファイルのリファクタリング

Antに対して、個人的に古臭さをどうしても感じてしまっている部分があり、あまり真摯な態度で読むことができず、反省しています...
ビルドファイル適当に書くな！って主張は当たり前過ぎるように聞こえましたが、改めて考えてみると、確かに開発環境構築の自動化とかを目的にして作られたシェルスクリプト(=本番環境で使用されないスクリプト)は人に見られる意識が希薄化して、中々ダーティーな作りになっていることを思い出し、わざわざアンソロジーを書いた理由が分かった気がしました。(自分自身への自戒も込めて記載...)

第11章 : 1クリックデプロイ

CI/CDツールの必要性は勿論、どういうプロセスステップでデプロイしていくのかやパイプラインのイメージなど、具体的な記載がありました。
最近聞いたfukabori.fmの以下のpodcastで出てきた話を脳裏に浮かべながら読んだことで、理解が深められた気がします。fukabori.fm

第12章 : アジャイルかウォーターフォールか

QAコンサルタントの方が記載されている章ということで、テストの話に焦点が絞られていました。
テストの種類が細かく記載されていて、章のタイトルにあるようにアジャイルとウォーターフォールでテストに求められることがどう違うのか記載されていましたが、「アジャイルだからこそシステムアーキや業務仕様など、テスト担当者の責務を超えるべきだ」という主張は違和感がありました。(開発手法に関わらずテスト担当者はただテストするだけの役割を担うべきでないと思うので...)
章全体としては、TDDを性能試験にも適用可能だという話とか、面白い話が複数あり、テストの目的と使い分けが改めて学べたので良かったです。

第13章 : 実践的な性能テスト

タイトルの通り、性能テストについて具体的に記載された章ですが、ただ理想を記載しているのでなく、現場で実際にありそうな障害についてもQA形式で記載されているのが好印象でした。
「顧客があまり技術に詳しくなく、不可能なことを要求する場合はどうするか」などはその好例で、快楽を求めただけ(早ければ早いほどいいでしょなど...)の性能要件なのか、業務的に必要不可欠な性能要件なのかを見極めるテクニックが書かれていて、学びが深い章でした。

全体

2008年出版なので少し古く感じる内容も一部ありましたが、殆どの内容は現代でも役立つものだったので、読んでみて良かったです。
アンソロジーというタイトルからは、ポエム的な文章や心構え集が連想されましたが、極めて実践的な内容で、具体性も高かったのが個人的には良かったです。

*1:非機能要求(性能要件)を検証するコストがあまりにも大きすぎる

*2:最近アップデートされた達人プログラマーに記載されていた、「毎年新しい言語を学べ」という教訓を思い出しました

*3:詳しくはこちらのブログを参考

*4:特にレガシーコードに対して使うと効果高いと思っています