クリーンアーキテクチャ本の読書メモ 第1章〜第2章

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Challenge Every Monthというコミュニティにて、上記本の輪読会が行われている。様子は以下を参照。

CleanArchitecture輪読会始まりました - もがき系プログラマの日常

自分は第4章から参加させてもらっている。みんなのペースに追いつくため、第2章まで読んだので、自分なりに読み取った・感じたことを雑にメモしておく。

第1章 - 設計とアーキテクチャ

ソフトウェアを世に出すことを優先し、クリーンな（優れている）アーキテクチャで設計・コードを書くことを怠けてしまうと、短期的・長期的にも生産性が落ちていく。

ということを感じとる内容が、とあるストーリーに沿って書かれている。

優れたクリーンなアーキテクチャとその意味を学ぶため、本書を読み進める。

第2章 - 2つの価値のお話

ソフトウェアとは、以下のような意味合い。

・ソフト ... 柔軟な
・ウェア ... 製品・プロダクト

HDD等のことをハードウェアと呼ぶが、それは振る舞いを変更できない（しにくい）製品であるから。

ソフトウェアは、要件に対して柔軟に変更できるべき。だが、現実はビジネスサイドの要件を半ば無理やりアーキテクチャやコード入れたことにより、変更コストが高く、事実上変更できないソフトウェアがある。

どんな仕事、ソフトウェアの要件についても、アイゼンハワーのマトリクスで以下の事柄に分けられるはず。

1. 重要かつ緊急である
2. 重要かつ緊急ではない
3. 重要ではないが緊急である
4. 重要ではないかつ緊急ではない

ビジネスサイドは、よく3の要件を1に昇華させがち。

ソフトウェア開発者は、アーキテクチャの重要性・ソフトウェアの保護を考え、ビジネスサイドと闘争すべき。

要件を先に取り入れ、アーキテクチャをおろそかにしてしまうと、ソフトウェアの開発コストは高くなり、一部または全部変更不可（凍結）となってしまうこともありえる。

所感

アーキテクチャを疎かにし、常に要件を反映していたプロダクトのことを思い出した。

そのプロダクトは、知る限り7年以上続いているが、クリーンアーキテクチャ本に書いてある通り、通常なら1日未満で終わる修正が、調査・検証のリスクを考慮して1週間かかることもざらだった。

この本からは、それを繰り返さないためのヒントが得られたらなと思う。