アジャイルソフトウェア開発の奥義 の商品レビュー

ロバート・C.マーチン【著】,ジェームス・W.ニューカーク,ロバート・S.コス【共著】,瀬谷啓介【訳】

2024/02/05

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

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

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

2023/01/14

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

2022/05/26

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

2020/10/05

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

2019/02/10

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

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

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

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

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

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

2018/10/07

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

2017/01/26

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

2012/09/13

デザインパターンの解説がまずあり、実際の開発で直面し解決した問題をベースに、具体的な設計や適用したデザインパターンについて、そこに至る検討や考え方も含めて書かれている。

筆者の体験した実例に基づいて
・アジャイル
・設計
・テスト駆動開発
・オブジェクト指向
・デザインパターン
の考え方、適用の仕方（実際にどう対応しどう失敗しどう修正したか）がじっくりと解説されていて読み応えがある。

各エッセンスについて多少の理解がないと結構難解になりそう。

2012/06/24

・きっかけ
BOSS

・キーワード
SOLID

・感想
原則を学び、原則を実践すること。
プロなら必読。

2012/06/03

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

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

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