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

本当に、ひたすら冗長で、そして実用性に欠ける書籍でした。DI(依存性の注入)を中心としたClean Architecture についてはwebにたくさんの情報があり、より詳細があるかと期待してこの本を買う人は期待はずれでしょう。Web以上の情報はありません。著者の Robert C. Martin("Uncle Bob"として知られる)は テスト駆動開発(TDD)の熱狂的支持者…いや扇動者として有名です。そして彼は今やおそらくコードを書いていません。この書籍の最初の30%はBobおじさんが語る、構造化設計、オブジェクト指向、関数型言語などのパラダイムの説明。そして彼の最もよく知られてる成果「SOLIDの原則」について語っています。いくつかの彼自身が仕事していた日々の楽しいトリビア(例えば、パンチテープから磁気テープに変わる時代の！)には価値を感じるなら別ですが、とても古い時代の、本当に、役に立たないエピソードです。「SOLIDの原則」やDIについても、全く知らない人にとっては説明不足であり、かつ、知ってる人にとってはただ冗長なだけです。。。この箇所が役に立つのは「SOLIDの原則」をある程度理解しつつ、やや誤解してる人…だけでしょう。どれだけ狭い読者層ですか？そして中盤の30%は、アーキテクチャーの話。コンポーネントの設計に関するたくさんの断片的知識がありますが、ひどく断片的です。彼のClean Architectureはアーキテクチャはフレームワーク、UI、データベースから独立しているべきだと述べています。彼の定義はコンポーネントの設計とコミュニケーションにのみ焦点を当てていますが、これはデータベース、フレームワーク、そしてUIの選択を自由にすることが出来るでしょう。ですが、そんな機会が頻繁にありますか？最大の利点はテストが出来ることです。これは本当に利点です。ただ、テストが必要な箇所のみDIでモックオブジェクトを差し込むことに比べて、Clean Architectureを使う利点がわかりません。実際に実装してみればわかるのですが、Clean Architectureは変更や機能追加にコストがかかり、データベース、フレームワーク、そしてUIの選択を含む設計上の決定が変わることはほとんどありません。つまり、コストが多くメリットが薄くなります。最後の40%は、考古学です！やったね！古代のハードディスク！プラッタが直径95センチ(38インチ)もあるくせに20MBしか容量がない！古代のディスプレイ！蛍光グリーンで72文字x25行も表示出来る！ただし大文字のみ！古代において最新の言語！C！(ぉぃそして「なぜ僕がボブおじさん(アンクル・ボブ)と呼ばれるようになったか」・・・といった自叙伝が続く。同人誌でやれってはいかげしょうか！高評価してる奴らはこの本をちゃんと読んだのですか？素晴らしい古代のお話が楽しいでしたか？現実の世界では、100％のテストカバレッジを持つ完璧なコンポーネントを作成するのではなく、実際に動くソフトウェアを求められるのはもちろん、「実際に動くアーキテクチャ」が求められています。もちろん、この本の中に書かれている思想的なものは多く有用ですが、文章的にも理解しづらく、後半40%は不要です。Bobおじさんはソフトウェアの保守性に注意を払いますが、スケーラビリティ、可用性、信頼性をほとんどを無視し、開発者の生産性を重視しません。私の経験では、ソフトウェアの設計と開発は、ビジネス要件、予算と納期の制約、および組織構造から始まります。これらは現実です。たとえば、この本には1文字たりとも、技術的な負債、リファクタリング、レガシーシステムへの対処については触れていません。「ウェブは何ひとつ変えてない。(中略)ウェブは入出力デバイスの一つである。抽象化できる」この一文だけでも、老齢のプログラマが一般法則を見出したしたり顔で話すような内容だとわかるでしょう。ならばなぜペーパープロトタイピングがあんなに最重視されるのか。体験こそ、UI/UXこそがコアユースケースでありビジネスロジックである時代に、彼はデータの保存と加工こそがコアだと思ってるのだ。（80年代は間違いなくそうでした！90年代も。2000年代も一部は…。2020年代でも重要なものの一つではあります）少なくとも、週次ビルドが良い習慣だとか、JSPやFlashだとかがあたらしい技術のように出てくる時代の書籍なのです。デイリーデプロイでCIが即時回って、スマホアプリでサーバレス…みたいな時代には部分的にしか役に立たない古典であり、更にその中で古典的な歴史の参照に40%が割かれている本である…そういうことは認識の上でご購入されたほうが良いと思います。