評判のいい「Clean Archtecture」を読んで役に立ちそう感あったので、章ごとに印象に残ったところを備忘録として書いてみる。
著者は通称「アンクルボブ」と呼ばれている1970年からプログラマをやってる超ベテランの人。この本が出版されたのが2017年なので50年近くプログラマの経験があることになる、
著者のキャリアで一番長いのはJavaによる業務システム開発だけど、WEB、組み込みといろんなシステムの構築経験がある人で、アーキテクチャ選定を間違えてしまったがために踏んできた地雷について様々語られている。
本の構成
第一部がイントロダクション、第二部がプログラミングパラダイム、第三部が設計の原則、第四部がコンポーネントの原則、第五部がアーキテクチャー、第六部が「詳細」第七部が付録で「アーキテクチャ考古学」について語られるという構成になっている。
第一部
導入箇所でソフトウェアアーキテクチャの定義だったり重要性、著者の紹介など。
ここでアーキテクチャの目的がこう定義されている
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである
第二部
プログラミングパラダイム
プログラミングパラダイムがテーマ。構造型プログラミング、オブジェクト指向プログラミング、関数型プログラミングなど。著者の意見としては「アーキテクトとプログラマは別のスキルセットだからアーキテクチャはプログラミングなど知らなくて良い」的なたまにある意見には反対派なので（というか今時賛成派の人いるのか、、）アーキテクチャの話に繋がる前提としてプログラミングについて語っている。
パラダイムの歴史的な教訓は、アーキテクチャとどのように関係しているのだろうか？「すべて」において関係している。
ソフトウェア（コンピュータプログラム）の本質は、「順次」「選択」「反復」と「間接参照」で構成されている。それ以上でも、それ以下でもない。
第三部
SOLID原則について
SOLID原則の目的としては
変更に強いこと 理解しやすいこと コンポーネントの基盤として、多くのソフトウェアシステムで利用できること
SRP：単一責任の原則
ここのモジュールを変更する理由がたったひとつになるように、ソフトウェアシステムの構造がそれを使う組織の社会構造に大きな影響を受けるようにする
OCP：オープン・クローズトの原則
既存のコードの変更よりも新しいコードの追加によって、システムの振る舞いを変更変更できるように設計すべきである
LSP：リスコフの置き換え原則
要するに、交換可能なパーツを使ってソフトウェアシステムを構築するなら、ここのパーツが交換可能となるような契約に従わなければならないということ
-
ソフトウェアを設計する際には、使っていないものへの依存を回避すべきだという原則
DIP：依存関係逆転の原則
上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳細側が方針に依存すべきであるという原則
第四部
コンポーネントの原則
コンポーネントとは、デプロイの単位のことである。システムの一部としてデプロイできる、最小限のまとまりを指す。
再利用・リリース等価の原則（REP）
再利用の単位とリリースの単位は等価になる
閉鎖性共通の原則（CCP）
同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。
全再利用の原則（CRP）
コンポーネントのユーザに対して、実際には使わない者への依存を強要してはいけない。
第五部
アーキテクチャ
アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである 最終的な目的は、システムのライフタイムコストを最小限に抑え、プログラマの生産性を最大にすることである
あと、組み込みシステムのアーキテクチャの話が、異次元だけど業務システムとかWEBとも共通するところありそうで「へー」ってなった。
第六部
詳細
アーキテクチャのエンティティ（構成要素）として語られないものについて。これを「詳細」と定義している。アーキテクチャに含まない方がいいものとして「データベース」、「ウェブ」、「フレームワーク」を挙げている。
データベース
データベースは、ディスクとRAMとの間でデータを移動する仕組みにすぎない。 アーキテクチャ的な観点からすると、回転する磁気ディスクに存在するデータがどんな形式であるか気にすることはない。
ウェブ
結論はsinnpuruda.GUIは詳細である。ウェブは詳細である。したがってウェブは詳細である。
-
フレームワークにはどんなリスクがあるのだろうか。ここでいくつか挙げてみよう
- フレームワークのアーキテクチャになんがあることが少なくない
- プロダクトが成長するに連れて、フレームワークの提供する機能では手に追えなくなってくる
- フレームワークが進化する方向が、あなたの望む道からずれてしまうかもしれない
- 優れたフレームワークを見つけたときに、乗り換えたくなる可能性がある
まとめとして
優れたアーキテクトは、システムのアーキテクチャが下位レベルの仕組みに汚染されることを許さない。
付録（アーキテクチャ考古学）
著者の長いキャリアの中で関わってきたシステムの話。アセンブラの時代からの話でアーキテクチャ軽んじるとどうなるか伝わってきた。。
