アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

著者 : ロバート・C・マーチン 瀬谷啓介

• SBクリエイティブ (2008年7月1日発売)

作品紹介・あらすじ

ソフトウェア開発の原則・デザインパターン・プラクティス完全統合。すべての悩めるプログラマのための処方箋。Software Development誌Jolt Award受賞作。

感想・レビュー・書評

[fleefloatingplanetさんの感想 · 2023年1月14日]

アジャイル開発とあるがオブジェクト指向設計の本である。SOLID原則などの原則や、デザインパターンを解説した後、模擬プロジェクトにてそれらをどう考えて適用していくかを示している。参考になるが、自分の力不足なのかコードが読みにくく、模擬プロジェクトのところは飛ばし飛ばしになってしまった。一旦読んだことにするがいずれまた読みたい。

[tshuuheiさんの感想 · 2012年6月3日]

具体例が多く、とてもわかりやすかった。
この手の本って抽象的過ぎると、「ボールをよく見て、いいタイミングでバットを振れば打てるよ」的な、「よく見てって言ったって自分ではよく見てるつもりなんだけどなぁ、いいタイミングって言われてもそれがわかれば苦労しないよ」って思うような感想を抱くことが多い。
だけどこの本は、
「ボールをよく見るってのはこうこうこういうことで、いいタイミングってのは具体的にこういうことだよ。じゃあ試してみよう。」っていう具合に説明が具体的で、例も豊富で、確かに知識が身につく感じがした。

デザインパターンや単体テストやリファクタリングに関する本を読んでたけれど正直消化不良だった。

それらがこの本を読んだことでやっとそれらを使えるようになり始めたと感じる。

[naQamuraさんの感想 · 2024年2月5日]

アジャイルソフトウェア開発はプロジェクトマネジメントやチーミングの話に終始しがちな本が多い中、技術面で成立させるための方法を解説してくれる本。著者が実際に経験したプロジェクトをモデルにして、サンプルコードをふんだんに使い説明してくれる。その分本が分厚くはなるが、説明量が理解しやすさに繋がっていて冗長なわけではない。

ただし、20年以上前のソフトウェア開発業界をモデルにしていることを留意した読み方は必要。受託開発で、C++やJavaなど静的型付け言語を利用、計算機リソースが今よりも高価で遅い、そんな時代背景。例えばコンパイルの時間を削減することを意識しているなど。またソフトウェアアーキテクチャの面でも進化を感じる。例えばDIパターンが発明・普及する前の内容なのでFactoryパターンだけを紹介している。

そういった留意点はありつつもおすすめな不朽の名著なことは変わらない。事業モデル関係なく複雑なユーザーニーズに向き合うプロダクト開発をする方々、そして自チームでのアジャイルソフトウェア開発サイクル実践に悩みを抱えている方々には是非読んでみて欲しい。

[nemupmさんの感想 · 2022年5月26日]

デザインパターンについては実例を元になぜその設計が良いのかを解説してくれます。また、筆者が実際に携わったプロジェクトなどを題材に、一から設計していくところを、思考プロセス含めて説明してあります。
また、決して各デザインパターンを手放しに褒めず、欠点や使い所などを丁寧に説明しています。
きちんと理解しながら読むのはかなり時間がかかりますが、内容としてはかなり濃く、一読の価値があります。
ただ、題材などが結構古かったりするので、現代を題材にした書籍にも期待です。

[budougumiさんの感想 · 2020年10月5日]

Twitterに雑に書いた感想メモ
https://twitter.com/budougumi0617/status/1312198952565891072

[mykelgさんの感想 · 2019年2月10日]

◆内容
めまぐるしく変化する仕様要求にさらされながらも、迅速にソフトウェア開発を進めていく「アジャイル開発」を実行するためには、

- 「実践法」の理解 (XP とか)
- 多くの先人達の失敗と経験から作られた「設計基本原則」の理解 (SRP, OCP, LSP, DIP, ISP とか)
- こうした原則をバランス良く利用した「デザインパターン」の理解

が必要だと述べ、それぞれについて詳細に語られている。

◆印象に残った点
◎テストファースト
　- テストファーストにすると、使う側の視点で見ざるを得ないため、早い段階でインタフェースに注意を払える。
　- テスト可能な設計にしようとすると、結果的に周辺コードと切り離され、ソフトウェアの分離を促す。結果的に設計の質を高める。
　- => いつもは正直、 設計->実装->テスト の順でしかできていなかったので、この考え方は納得した。（本でも、先に実装して後からテストを加えてやってみた経験談を元にした小説があり、「テスト先に加えておけば手戻りせずにすんだな」という気づきが書かれていた。）

◎リファクタリングをすべきか？
　- もともと最初からプログラムは正しく機能していたのに、わざわざ時間を割いた価値はあるのか？
　- 筆者の答え「書き上げるモジュールと保守するモジュールのすべてを必ずリファクタリングすることを強く勧める」
　- 興味深い例え：リファクタリングは食後のキッチンを片付けるようなもの。最初は後片付けをしなければ、それだけ食事時間は短くて済むが、やっておかないと、翌日の食事の用意をするときにもっと時間がかかってしまう。そこでまた後片付けしたくなくなる。実際片付けをしなければ、その日の食事は早く終えることができる。しかし、キッチンはどんどん汚くなっていく。ついには、必要な調理用具を探すだけでとんでもない時間が費やされてしまう。乾いて皿にこべりついた食べ物を引っペ返して、ごしごしあらうだけで大変だ。これでは、いつまでたっても食事にありつけない。結局、後片付けを怠れば、食事にかかる時間は長くなるのだ。

◎ソフトウェア開発で一番変化するのは仕様であり、最も不確実な要素は仕様である。アジャイルは、仕様変更（変化）でソフトが腐敗しないような開発方法の実践法を示している。

[Cognosce te ipsumさんの感想 · 2019年1月20日]

再読必須。

[ichiro.marinersさんの感想 · 2018年10月23日]

ソフトウエア開発に最も重要な要件は、・レベルの高いスキルを身につけたソフト・エンジニアを集める・上記エンジニアの集団を、協調と対話ができる文化を持ったチームにすることである。　本書は、両要件について非常に深い示唆、提言を行う極めて重要な書籍である。特にソフトウエア・エンジニアリングの最重要技術であるオブジェクト指向プログラミングについて、詳細且つ丁寧な解説を行うことで、前記要件のエンジニアを育てることに有用である。　本書が提言するオブジェクト指向の奥義に触れずに書評をするわけにはいかないので、少しサマライズしておこう。　本書でまず、下記のようなソフト開発における重要原則を例を用い、解説する。・シンプル・イズ・ベスト　　なんでもオブジェクト指向にする必要はなく、必要十分な複雑さに留めるべき。・単一責任の原則（SRP:the Single Responsibility Principle）　　オブジェクトは、複数の責任を持つべきでない。・インターフェース分離の原則（ISP:Interface Segregation Principle）　　クライアントに、不要なメソッドの依存を強制しない・オープン・クローズの原則(OCP:Open-Closed Principle）　　ソフトウエア構成要素（クラス、関数など）は、拡張に対して開いていて、修正に対して閉じてなければならない・リスコフの置換原則（LSP:Liskov Substitution Principle）　　派生型は、その基本型と置換可能でなければならない・依存関係逆転の法則（DIP:the Dependency Inversion Principle)　　上位モジュールは下位モジュールに依存してはならない。　　抽象は、実装の詳細に依存してはならなく、実装の詳細が抽象に依存すべき。その後、これらを用い、下記のデザインパターンを仕様したプログラミングの実例を紹介する。・Commandパターン、Active Objectパターン・Template Methodパターン、Strategyパターン・Facadeパターン、Mediatorパターン・Signletonパターン、Monostateパターン・Null Objectパターン・Factoryパターン・Compositeパターン・Observerパターン・Abstract Serverパターン、Adapter・Proxyパターン、Stairway to Heaven・Visitorパターン・Stateパターンほとんどのプログラミング例はJAVAで書かれている（一部C++）が、型付けの強い言語を使っているプログラマーのみでなく、すべてのオブジェクト指向プログラマーに極めて重要なヒントを与えてくれるだろう。なお、本書は、<a href="http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/ichiromarin09-22/ref=nosim" target="_blank">アジャイルソフトウェア開発の奥義</a>の第２版である。本書とあわせて読むことをお勧めする。

[isopさんの感想 · 2018年10月7日]

アジャイル開発について、XPを軸にプラクティスがまとめられています。 後半は、様々なルールを壊さないためのデザインパターンの解説、という感じです。 アジャイルアライアンス宣言で ・プロセスやツールよりも、<b>人と人同士の交流を</b> ・包括的なドキュメントよりも、<b>動作するソフトウェアを</b> ・契約上の交渉よりも、<b>顧客との協調を</b> ・計画に従うことよりも、<b>変化に対応することを</b> とありますが、個人的に重要なのは、2,4番目と感じました。(この時点で自分はアジャイル向きではない) 変化に対応しつつ、きちんと動くソフトを作るために、テストを重視し、変更しやすいようなコードを書く、ということの重要性を改めて考えることができました。 デザインパターンは、(この手の本ではありがちですが)例がわかりにくいので、実践しながら参照するほうがよさそうです。

[fujiyamaeggさんの感想 · 2017年1月25日]

「アジャイルソフトウェア開発宣言」の「包括的なドキュメントよりも動くソフトウェアを」という考えが、本書を通底して流れているように思える。我々は、この本を通読することで、アジャイル開発を疑似体験することができるのである。ただし、ここでの「アジャイル」とは、組織文化に着目したスクラム的なものではなく、プログラマーの復権を目指したXPであるけれども。
この書籍は、設計原則とコード例で満ち溢れている。もちろん、必要最低限のクラス図、シーケンス図などのモデルも随所に記載されている。もし、この書籍を腹落ちしながら読み通すことができれば、本当に素晴らしいソフトウェア開発者になることであろう。私も残念ながらそのレベルには至っていないが、そこに到達したいとは思っている。
本書に記載されている設計原則は、あまりにも有名である。この設計原則のおかげで、本書は「古典」になっている。これはアジャイル開発とは関係なくとも、すべてのソフトウェア開発者が読むべき文章であると思う。