【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅰ部
概要
直近、クリーンアーキテクチャを採用しているプロダクトを開発する部署へ移動したため、クリーンアーキテクチャへ入門するために、タイトルの本を読み進めることとした。
この記事に目的は自身以外の理解を助けるために要約や、議論を生むために自身の考え方を残すために書かれている。
要約
第1章 設計とアーキテクチャ
この章では設計とアーキテクチャとは何なのかについて書かれた章である。
結論として、設計は詳細、アーキテクチャは抽象度の高いものとして扱われるが、どちらも相互に決めあう性質を持つため実質的には同じである。
設計とアーキテクチャの目的は二つあり以下の二つである。
- 労力の最小化
- 生産性の最大化
クリーンアーキテクチャもこれを満たすために存在する概念である。
しかしプログラマは、あとからクリーンなコードに修正できると思い込みデリバリーを優先してしまうことが多い。実際には市場の圧力は止まらず、その機会は訪れない。
では最初からクリーンなコードを書くのが遅いのか?
答えは、そうではない。
クリーンなコードを書けることで有名なTDDを利用した場合、全体的に10%早くコードが書けるようになった実験結果もある。
つまり、早く進みたいならうまいやり方で進むべきである。
ちなみにスクラッチで再開発する際も、上記の意識がなければ無駄なこととなる
第2章 2つの価値のお話
プログラマが提供する価値には2つある。
- ふるまい
- 要件を満たし、実際に顧客を満足させるもの
- アーキテクチャ
- ソフトウェアの設計、つまり「ソフト」で変更が容易な状態を目指す。
ではどちらの方が価値が高いか?それはアーキテクチャである。
ビジネスには必ず変更が求められる。アーキテクチャがダメだと、必要な変更コスト>ビジネスパフォーマンスになっていくため、実質的に変更が不可能な状態になるからである。
開発が進んでいくと、プロダクトが大きくなるにつれて、工数がスコープに比例しなくなっていく傾向が見られる。スコープが同様でも工数が肥大化しているということはアーキテクチャ崩壊の合図となっている。
ふるまいとアーキテクチャを重要度と緊急度のマトリクスに当てはめると上記の話に従って以下のようになる。
- ふるまい
- 常に緊急、重要かどうかは場合による
- アーキテクチャ
- 常に重要、緊急かどうかは場合による
ただし、ビジネスマネージャーはアーキテクチャの重要性を理解することは難しいため、プログラマはアーキテクチャの重要性を評価し、主張する責任を持つべきである。
まとめ
概ね同意できる内容だった。
ビジネスマネージャーはアーキテクチャの重要性を理解することは難しいため、プログラマはアーキテクチャの重要性を評価し、主張する責任を持つべきである
本筋とはズレるが、この視点を持てるかどうかでインハウスエンジニアとしての価値は大きく変わると考えている。
Discussion