【Clean Architecture】1章 設計とアーキテクチャ
「Clean Architecture」の学習記録。
「第1章 設計とアーキテクチャ」のまとめ。
設計とアーキテクチャ
本書の目的は、設計とアーキテクチャについて定義することである。
- 通常「アーキテクチャ」という言葉は、下位レベルの詳細とは切り離された文脈で使用されている。
- 一方、「設計」という言葉は、下位レベルの構造や意思決定を意味している。
著者は両者に違いは無いと考えている。
下位レベルの詳細と上位レベルの構造は全体の設計の一部となる。
それらが連続した想像を作り、システムの形状を定義する。
どちらも欠くことはできず、また両者を明確に区別することはできない。
最上位レベルから最下位レベルまで決定の連続である。
ソフトウェアアーキテクチャの目的
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
設計の品質は、顧客のニーズを満たすために必要な労力で計測できる。
必要な労力が少なく、システムのライフタイム全体で低く保たれていれば、その設計は優れている。
逆に、リリースごとに労力が増えるなら、その設計は優れていない。
崩壊のサイン
コード1行あたりにのコストや、生産性をリリースごとに計測することで、プロダクトが崩壊に向かっているか分かる。
システムを慌てて構築しているとき、コードがクリーンであることや設計の構造について配慮が欠けているとき、これらの計測値は曲線に乗ったまま最悪な結末を迎えることになる。
本書のグラフでは、最初の生産性は100%だったが、リリースの度に生産性が低下し、4回目のリリースでは生産性は底を打っている。
開発者視点では、誰もが一生懸命働いていて手を抜いている訳ではない。
しかし機能の開発ではなく、崩壊の対応に追われているのである。
ある場所の対応が終われば次の場所、また次の場所と崩壊の対応を続けていると、機能の開発はできなくなる。
何が間違っていたのか？
「ウサギとカメ」のウサギのように、開発者も自信過剰な競争をしている。
開発者は猛烈に働いているが、脳は眠っている状態である。
優れた、クリーンな、うまく設計されたコードが重要であることが分かっていない。
崩壊したコードを書けば、長期的には開発の速度を低下させるが、短期的には速度は上がる。
これを信じている開発者は、崩壊したコードを書くモードから、いずれどこかでクリーンにするモードに切り替われる、というウサギのような自身を持っている。
しかしそれは事実誤認である。
事実は、短期的にも長期的にも、崩壊したコードを書く方がクリーンなコードを書くよりも常に遅い。
本書の例では、テスト駆動開発（TDD）を行った場合と行っていない場合の実験があり、TDDを使った方が全体的に10%ほど速い。
ここから分かる真実は、速く進む唯一の方法は、うまく進むことである。
生産性の低下とコストの増加を回復させる唯一の方法は、開発者にウサギの自信過剰な思考をやめさせ、自ら生み出した崩壊に対して責任を持たせることである。
システム全体を再設計すれば良いと考えるかもしれないが、現実はそれほどうまくはいかない。 自信過剰による再設計は、元のプロジェクトと同じように崩壊する。
