アジャイルソフトウェア開発の奥義

最近読んでいる本がこれっ！ 読んでると、新しい発見が次から次へと涌いてきます！

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

オブジェクト指向の五原則・・・

• 単一責任の法則（SRP）
• オープン・クローズドの原則（OCP）
• リスコフの置換原則（LSP）
• 依存関係逆転の法則（DIP）
• インターフェイス分離の法則（ISP）

を徹底的に解説した後、デザインパターンを上記原則との関係から詳しくひもとき、ケーススタディではパターンを使って設計するヒントを、実践的に詳しく解説しています。
どのパターンをどの場面で活用するか、また設計が複雑にならないよう、パターンを使うべきでない場合など、オブジェクト指向の原則に基づいたアジャイル的設計テクニックを、それはもう徹底的に詳しく解説している良書です。また翻訳がこなれているので大変読みやすい！読んでいて頭にスイスイ入ってきますね。「オブジェクト指向開発の神髄と匠の技」・・・まさに副題とおりの内容です。

また付録も面白いです。付録C 「皮肉な運命」では、旧来の設計手法により悲惨な最期を遂げたプロジェクトと、アジャイルにより成功したプロジェクトを同時進行で対比しつつ、辛辣なジョークを交え面白おかしく描いているわけですが、どこかで聞いたことがあるような破綻したプロジェクトの進行状況などは、笑うに笑えないものがあります。

あと結構ヒントになったのが、以下の文。

データベースは実装の詳細にすぎない！データベースについて深く考えるのは、できるだけ後回しにするべきだ。最初からデータベースの存在を前提に設計してしまったために、データベースにがんじがらめにされているアプリケーションは多い。抽象化の定義が「本質を浮き彫りにし、無関係な部分を排除する行為」であることを思い出して欲しい。データベースの詳細に拘泥することは、プロジェクトの初期段階では的外れである。データベースは、データを保存したりそのデータにアクセスしたりするための単なる道具にすぎないのだ。

アジャイルソフトウェア開発の奥義 第二版 P249

一般に、データベースの実装は「詳細」だと私は考えている。こういった詳細を決めるのは、できるだけ先延ばしにした方がいい。ここで扱っているデータベースが RDBMS で実装されようが、フラットなファイルシステムで実装されようが、OODBMS（オブジェクト指向データベース管理システム）で実装されようが、この時点では関係ないことだ。今この時点では、アプリケーション全体にデータベースサービスを提供する API を設計することだけに関心がある。・・・
このように、データベースの詳細について考えることを後回しにすることは珍しくない。これはいけないことではなく、逆に、とても恵みの多いプラクティスだと言える。通常、取り組んでいるソフトウェアのことをもっと知り、それが何を必要としているかを深く理解するまで、データベースの詳細は先送りすることができるものだ。このように待つことで、データベースに多くのものを詰め込み過ぎるといった問題を回避できる。むしろ、アプリケーションのニーズに見合うだけしかデータベースを実装しないのでちょうどいい。

アジャイルソフトウェア開発の奥義 第二版 P267

データベースとクラス設計の関係って、前から結構悩みの種だったのですよねぇ〜。

私は最初に師事した人達の影響か、まずクラスの構造よりもスキーマの構造中心に考える方だから、作るシステムがどちらかというと DB に依存した構造になりやすい。後からスキーマに変更が発生した場合などは、リファクタリングしながら何とか対処している訳ですが、クラスを意識して細分化しまくってるおかげで修正はあまり苦にならないものの、クエリは逆に複雑になったり、またテーブル構造に縛られた不愉快なクラスがシステムに多く存在したりします。そんな訳で、どうすれば DB に極力依存しない、シンプルなクラス設計ができないものかと常々考えていた訳ですが、この本で目が覚めました！

データベースについて深く考えるのは、できるだけ後回しにするべきだ。

・・・このように待つことで、データベースに多くのものを詰め込み過ぎるといった問題を回避できる。

なるほどですっ！！そう考えると TableAdapter が一見開発効率を上げるフレームワークのように思えても、スキーマの変更があるとたちまち融通が効かなくなり、修正にてこずるようになったりするのも道理な気がします。

もう少しこの本と出会うのが早ければ・・・今更ながら悔やまれますね。(＾ω＾;