まいくろ🍣きりみん

きりみんのマイクロブログです。ブログとTwitterの中間くらいの文章を書きます。

「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ感想。誰のための設計か

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

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

読みました。個人の感想を書きます。
この本は「Clearn Architecture」というタイトルからは"例の"クリーンアーキテクチャの解説本なのかなという印象を受けるが、実際には"例の"クリーンアーキテクチャとはほとんど関係がないし、それどころかこの本に具体的な実装パターンや課題の解決方法などは出てこない。
この本に書かれているのは、「アーキテクチャとは何であって何ではないか」ということだ。

内容

この本の面白いところは、アーキテクチャについて語る本でありながら、一般的にアーキテクチャと呼ばれるものを基本的に批判していることだ。
この本では、一貫して早すぎるアーキテクチャの決定やオーバーエンジニアリングを否定している。(とぼくは思った)
アーキテクトの仕事はプロジェクトの開始時に最高に美しい設計を決めることではなく、常にその組織やプロダクトの状態に合わせて柔軟に変更出来る余地を残した設計を考え、状況に応じて改善を繰り返すことだ。そのためには使用する技術などの意思決定を出来るだけ遅らせることが大切で、結果としてデータアクセスやUIといった外部に依存する部分の実装の詳細を隠蔽し切り離すことを推奨している。

上記は「Clean Architecture 達人に学ぶソフトウェアの構造と設計」本文からの引用である。
この本に書かれている内容は、モダンでクールなアーキテクチャを構築するための秘密のテクニックではなく、長年ソフトウェア開発と戦ってきた著者によるアーキテクトの失敗や成功に関する知見だ。

なお、本書の半分くらいは設計原則の解説とプログラミングの世界の昔話なので読み飛ばしてもさほど問題はないと思う。

感じたこと

この本の内容は自分にとってなかなかタイムリーであった。
なぜなら、自分自身も「美しい最高のアーキテクチャ」を追い求めるという昨今の風潮や、実際のコストや生産性、柔軟性よりも特定のアーキテクチャの指針や設計原則を厳守することを重視した方針などに対して疑問を感じていたからである。

アーキテクチャ、設計というのは誰のために行うものなのか。
もちろん答えは一つではないと思う。しかし、「流行りに乗り遅れないため」や「最先端の思想を取り入れるため」に決めるものではないとは思う。
ぼくがMVPという設計に興味を持って色々な検証をしたり考えたパターンを公開したりしていたのは、そこに課題があったからで、どういうコードを組めばその課題が解決出来るかを考えていたからだ。

個人的には課題が特にないのであれば極力コードの構造はシンプルな方がよいと思っている。
MVPですら、特に必要がないと思えば無理して導入する必要はないと思う。
しかし一般的にMVPやMVVM、最近のAndroidでいえばAACやRxを導入することでコードをより扱いやすいものにすることが出来るので、多くのプロジェクトが取り入れているのだと思う。

なので、例えばdatabindingですらも、ぼくはシンプルにメリットが享受出来る範囲では使いたいと思うが、トリッキーなコードを書いてまで全ての処理をdatabindingに寄せたいとは思わない。RxJavaやRxBindingに関しても同じだ。

Fluxなどもそれが生産性や保守性、可読性や品質に寄与するのであれば価値があると思うし、状態やデータの扱いに特に大きな課題感を感じていないのであれば無理に導入する必要はないと思っている。

何が言いたいかというと、業務でのソフトウェア開発、アーキテクチャ、クラス設計、きれいなコード、すべては最終的にプロダクトの実現したいことを叶えるため、「こういうことがやりたい」という要件に対して「これだけ早く高品質に要件通りに作ることが出来ます」といえるようにするためにあるのだと思う。
なので、「コードを共通化したいから」「設計原則を守りたいから」という理由で要件に対してNOを突きつけるのはプロダクトを開発するソフトウェアエンジニアとしてはナンセンスだと思うし、誰のための設計なのか、ということを常に意識したいしして欲しいと思う。
(「要件により仕様やコードが複雑になりすぎて今後の開発の生産性や品質に悪影響があるのでその仕様は避けたい」というのはプロダクトのことを考えた思考だと思うし悪くないと思う)