【感想】Clean Architecture 達人に学ぶソフトウェアの構造と設計
「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読みました。
著者について
著書であるロバートC.マーチン氏は「ボブおじさん」の通称で知られており70歳のおじいさまです。1964年（著者12歳）から半世紀以上コードを書き続けている方で、本の中では著者の豊富な経験（昔話）をいくつも書かれています。
プログラマーなら知っているであろうSOLID原則の提唱者としても知られています。また、テスト駆動開発の推奨者でもあり本書でも「TDD良いよね」的なことが書かれています。
プログラムの価値とは
本書を読んでびっくりした項目です。
機能? それともアーキテクチャ? 価値が大きいのはどちらだろうか? ソフトウェアシステムが動作することが重要だろうか? それとも､簡単に変更できることのほうが重要なの だろうか?
p43 アイゼンハワーのマトリックス
普段プログラマとして雇われ働いていると、「プログラマの仕事=仕様通りに動くプログラムを実装すること」と思うのではないでしょうか。（アーキテクトになるとただ仕様どおりに実装するのではなく、セキュリティやパフォーマンスなどの懸念点を洗い仕様をチェックする役割もあると思いますが）
しかし、本書ではもっとも価値が高いのはソフトウェアシステムが動作することではないと書かれています。
・完ぺきに動作するが､変更できないプログラムを与えられたとする。 要件が変更されると 機能しなくなる。 修正することもできない。したがって、このプログラムはいずれ役に立たなくなる。
・動作しないが、変更が簡単なプログラムを与えられたとする。 要件が変更されても修正は 可能なので、動かし続けることができる。したがって、 このプログラムはこれからも引き 続き役に立つ。
p43 アイゼンハワーのマトリックス
つまり、仕様どおり完璧なコードよりも、たまにバグるが変更が容易なプログラムの方が価値が高いということが書いてあります。
この章を読んで、細かな仕様を実現するためにちょっと変なコードを書かざるを得ない問題に直面した経験を思い出しました。（当時は不具合を許容してもらうよう意見が言えず無茶なコードを書きました。。。）しかし、将来の柔軟性を考えるとPMに意見をして「この変更をする場合、今後機能を追加するときにコストが増えます」…と補足出来たら良かったのかもしれません。難しい。
プログラミングパラダイム
第二部の最初では1983年、コンピュータプログラミングの基礎の確立を経てアセンブラやコンパイラの登場について触れています。
自分が産まれる前の話なので歴史書を読んでいる気分でした。イギリスの数学者であるAlan Turing氏は当時バイナリでプログラムを書いていたというエピソードには驚きました・・。バイナリでループや分岐、代入、サブルーチンなど書いていたそうです。また、第二次世界大戦でも暗号通信を解読する責任者になりとても優秀な方だったんだなと思いました。しかし41歳という若さでショッキングな最期を遂げています。気になる方はWikipedia覗いてみてください。
また、1951 年に世界初のコンパイラ「A-0 system」を考案しコンパイラという言葉を産み出したGrace Hopper氏も印象的でした。イェール大学大学院を卒業後数学と物理の修士を取得しアメリカ海軍に従事された女性です。アメリカの科学技術界は、今よりずっと男女差別が激しかったと聞きますが、このように活躍された方がいるんだなと思いました。
彼女で少し面白かったのが、“バグ”と戦った歴史的プログラマーという記事にある1940年代のエピソードです。
あるとき、後継機の「マークII」の内部に蛾が飛び込んで正常に作動しなくなったが、ホッパーが取り除いて修復したという。コンピューター分野でプログラムの不具合などを「バグ」（英語で「虫」の意）と呼ぶ風習が広まったのは、この出来事がきっかけと言われている。
本当かは分からないですが、こんな由来があったんですね笑
設計について
第三部では下記のような設計の原則について説明があります。一通り読んでおくと勉強になるなーと思いました。
SRP: 単一責任の原則
OCP : オープンクローズドの原則
LSP:リスコフの置換原則
ISP: インターフェイス分離の原則
DIP: 依存関係逆転の原則
内容は本書を読んでみてください。
また、タイトルにもなっている「クリーンアーキテクチャ」についてですが、読む前はすべてがクリーンアーキテクチャについて書かれている本だと思っていたのですが、実際は第五部の22章で触れられている程度になります。
有名なこの図です。
「感心ごとの分離」について説明がされており、レイヤーに分割することで分離が実現できます。
・フレームワーク非依存：アーキテクチャは､機能満載のソフトウェアのライブラリに依存 していない。これにより、システムをフレームワークの制約で縛るのではなく、フレームワークをツールとして使用できる。
・テスト可能 : ビネスルールは、UI、データベース、ウェブサーバー、 その他の外部要素がなくてもテストできる。
・ UI 非依存： UI は、システムのほかの部分を変更することなく、簡単に変更できる。たとえば、ビジネスルールを変更することなく、ウェブ UI をコンソール UI に置き換えることができる。
・データベース非依存： Oracle や SQL Server を Mongo, BigTable, CouchDB などに置き 換えることができる。 ビジネスルールはデータベースに束縛されていない。
・外部エージェント非依存：ビジネスルールは、外界のインターフェイスについて何も知らない
このようなルールに従いレイヤーに分割したアーキテクチャを図や実際のビジネスルールを踏まえて説明してくれます。ルールに従って設計しようと思うと抽象的なロジックをたくさん書く必要があるので結構大変そうだなーという感想でした。
自転車に乗るように、ソフトウェア設計の本を読むだけで習得することはできない。本書などから得たことを実際に生かすには、練習するしかない。
と書いてあるように実践あるのみです。結構分厚い本ですが、読み応えありましたのでぜひご一読ください。
スキ頂けると嬉しいです〜