Clean Architecture 達人に学ぶソフトウェアの構造と設計
Clean Architecture 達人に学ぶソフトウェアの構造と設計という本を読みました。
ずっと前（発売日）くらいに買っていて、ずっと読もう読もうと思って積んでいてたので、いい加減読みたいなぁと思って読みました。
読み始めたときに、なんでもっと早く読まなかったんだろうと少し後悔しました。
プログラム言語のパライダムの歴史や、SOLIDの原則を説明していて、その後具体的にじゃあどうすれば良いのか、ということを示してくれている本でした。
引用元：
一枚の絵でクリーンアーキテクチャをまとめている画像がこれです。
外側がDBやフレームワークやIFを担当していて、外部ｰ>内部は依存するが、内部ｰ>外部は依存しないというものです。
個人的に今まで作成してきたソフトウェアもなんとなく階層化をしていたけれども、4段階と明確には分けてなかったし、なるべく疎結合にするようにはするものの、明確に依存性の方向までは意識出来ていなかったので個人的には衝撃的でした。
これからは、この図を意識してプログラミングしていきたいと思います。
また、28章にはテスト境界という章があります。
この章では、テストはなるべく壊れないように設計しなければいけないよねということが書いてありました。
具体的な例が書いていないのでなんとなくしか理解できていないですが、理想はUIに依存しないようにするだけではなく、DBなどにも依存しないようにビジネスルールを検証できるAPIを用意しようということなんだろうと思います。
確かにこの設計は最初からやらないと難しいと思うけれど、実際どうやる想定なのかがちょっとわからなかったです。時間があったら調べたいと思いました。
29章には組み込みに関しての記述があります。書いてあることにはほとんど同意できる内容でそうだよなぁと思いながら読みました。
ファームウェアやOS、ソフトウェアの境界はしっかりインターフェイスを設けようということが書かれています。
実感としてLinux向けのソフトウェアじゃないもののテストを自動で走らせるのはなかなか出来ないので、RTOSなどのOS依存のコードをレイヤーで分けておかないといけないということは前から思っていたことなのですが、そういった疎結合にする方法の内容がずばり書いてありました。
ファーム、OS依存を分けられると、ハードやOSが変わったときに大変な思いもしなくて済むんだろうなぁと思います。
訳者あとがきにはフレームワークの選定後回しにすることがあるのだろうか？と書いてありますが、実際には結構あると思います。
どういうフレームワークを使うか、どういうDBを使うか、どういうプロトコルを使うかということは後から変わることがあって、やっぱりあっちが良いとなることもあります。
そのために切り離すことが重要なんだろうなぁというのが個人的な実感です。
久々に長い感想を書いてしまいましたが、すべてのプログラマーの人に読んでほしいと思える本でした。
