「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

感想

仕事でアプリケーションの設計や、すでに出来上がってるアプリケーションのリプレイス業務などに携わっているので、アーキテクチャの参考にすべく読んだ。

感想としては、率直に面白かった。すべての内容を理解できたわけではないが、今自分が現実で戦っている問題に直接的につながってる所もあり、（SOLID原則あたり）、興味深く読めた。表題の「クリーン」だったり「達人に学ぶ」だったりが若干おそろしくて今まで手をつけられてなかったけれど、内容としては読みやすい部類だと思う（平易ではない）。

アプリケーションの開発が進むにつれ、ある部分の変更点がどこまで影響を及ぼすのか見通しがつかなくなったり、テストしたい部分があまりに巨大になったり、といったことはよくあることだと思うけれど、そういった問題点に対する取り組み方を教えてくれる内容、といった印象だった。

具体的なコードがそこまで多く記述されているわけではないが、コンポーネント間の依存関係の説明のさいは図が多くてありがたかった。

また、フレームワークの選定だったり、使用するRDBMSの選定を遅らせる開発手法について紹介していたけれど、訳者あとがきでも合ったとおり、それはあまり現実的ではなさそうだとは思った。そこは詳細・具体で、原則的に依存は避けるべきものではあるものの、依存しても問題ない箇所ではないかと思う。なぜなら、現実ではそれらが「変更されること」がとても少ないからだ。

Railsで書かれたアプリを、Sinatraに移す、なんてことはしないと思う。現実的には、Railsで苦しんだ開発者は、言語もアーキテクチャーもなにもかも刷新する「フルリプレイス」を選択することが多そうだ。ただ、Railsから少しずつマイクロサービスに移行するというケースはありそうなので、（できれば）それらは考慮した設計の方がよさそうという観点もあるので、簡単に断言はできない。

一つ言えるのは「設計論」は現実の問題を解決するための手法なので、現実の方にフォーカスし続けなければ無意味になるということ（これは本書でも似たようなことが言われていた）、あくまでも武器の一つとして、本書の内容を覚えておきたい。

メモ

印象に残った部分と、その部分に対する感想をメモ。

第1部

2章

ソフトウェア開発者のジレンマは、ビジネスマネージャーがアーキテクチャの重要性を評価できないことである。 ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる。

ビジネスにおいて一番価値としてわかりやすいのは機能だけれども、ソフトウェア開発者としては、運用まで見込んで、機能追加・変更・拡張について門戸が開いているようなアプリケーションを作る重要性については話すべきだなあ、と上記の文を読んで思った。

たしか、この本のどこかに書いて合った言葉（どこか忘れた）で、「作るのは簡単だ、動かし続けるのが難しい」みたいな言葉があったとは思うが、自分も賛成である。特に動いているように見せるのは簡単だ。しかしアプリケーションの本質的な価値は、まず動かし続けることから生まれると思っている。

第2部

6章

●構造化プログラミングは、直接的な制御の移行に規律を課すものである。 ●オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである。 ●関数型プログラミングは、代入に規律を課すものである。 これら3つのパラダイムは、我々から何かを奪っている。 (中略) 過去半世紀にかけて我々が学んだのは、何をすべきではないかである。