「Clean Architecture　達人に学ぶソフトウェアの構造と設計」 を読んで気になったところを抜粋 その1

この記事は、岩手県立大学アドベントカレンダー7日目の記事です。

2018年のアドベントカレンダーは、1日目から6日目まで一人で書いていたことを考えると、2019年は盛り上がっていますね！

さて、本日のテーマ「Clean Architecture」は、Robert. C. Martin (Uncle Bob）が提唱するソフトウェアアーキテクチャです。同心円の図とともにどこかで見たり聞いたこともある方も多いのではないでしょうか。

2019年初頭、僕が携わることになった某プロジェクトが Clean Architecture を採用しているということだったので、提唱者である氏の書いた本の邦訳である「Clean Architecture　達人に学ぶソフトウェアの構造と設計」を読んでみました。

実際に読んでみると、ネット上で取り上げられているような内容とはかなり違うことに気づきます。というのも 「Clean Architecture」という言葉を明確に取り扱うのは22章の数ページだけなのです。

ネット上の記事では、言語による実装例とともに「こうつくるべき」という部分が強調されています。しかしながら、本書では、より大きな視点でソフトウェアアーキテクチャを解説し、より抽象的あるいは大局的な見方で Clean Architecture がなぜ必要なのか？どういう思想なのかが丁寧に述べられています。そもそもアーキテクチャなのだから本来はコードレベルの実装方法を規定するものではないのです。そこには、ネット記事と本書の大きなギャップがあります。

さて、この記事では、本書を読んで僕が気になったところ（kindleハイライトをつけたところ）を引用と僕からのコメント形式で羅列します。はじめに述べておきますが、長いわりにとりとめのない内容です！

Clean Architecture の真髄はしっかり読んだうえで周囲のエンジニアと議論をしていかねば理解できないと思います。もし興味があれば本書にあたってみてください。僕もより理解したいので議論に招待してください。

--

現代のソフトウェアを過去のものと比べて気づくことがもうひとつある。使われている素材は今も昔も変わっていない。

現代につながるコンピューターの発明以来、70年以上、順次、分岐、繰り返しの構造は一切かわっていません。ちなみにもうひとつは、「機械は感情を持っていない」ということを述べられていました。

--

プログラムを動かすために膨大な知識とスキルが必要となることはない。
（中略） 何かを「一度だけ」動かすのはそれほど難しくないのだ。
ソフトウェアを正しくするのは完全に別問題である。正しくするのは難しい。

一見すると難解なのですが、「正しくする」というのを「正しく作る」に読み替えるとすっときます。プログラムは言われたとおりにしか動かないので、プログラムを動かすのは簡単なのです。難しいのは「ソフトウェア」を「正しく」作るということ。これは経験だけでなく、情熱も必要でしょう。

さらにいえば、「プログラムとソフトウェアの違いは？」「正しさとはなにか？」を理解している前提にるのではないでしょうか。

--

プログラミングパラダイムは、プログラマから能力を削除しているのである。新しい能力を提供しているものではない。それぞれがネガティブな意図を持ち、何らかの規律を課しているのである。これらのパラダイムは、何をすべきかを伝えるよりも、何をすべきでないかを伝えているのである。

この表現は、目からうろこでした。多くのエンジニアは、構造化プログラミングからはじまり、オブジェクト指向プログラミング、そして、関数型プログラミングに出会っていく場合が多い。

その出会いの過程で、「なにか新しいものがあるらしい！」「これまでのパラダイムに比べてどんなことができるんだ？どんな機能があるんだ？」という面でみてしまいがちです。しかし、本質は「こういうことができない」ということであると述べられています。

ちなみにそれぞれどういう規律であると述べられているかというと、、、

・構造化プログラミング ･･･ 直接的な制御の移行に規律を課すものである。
・オブジェクト指向プログラミング ･･･ 間接的な制御の移行に規律を課すものである。
・関数型プログラミング・・・代入に規律を課すものである。

これまた難解。特にオブジェクト指向プログラミング。本書が述べたい意図は本書に譲る。

そして、これらのアーキテクチャは、それぞれ次の関心事から生まれたとまとめている。

・構造化プログラミング ･･･ コンポーネントの分離
・オブジェクト指向プログラミング ･･･ データ管理
・関数型プログラミング・・・機能（注: 関数やサブルーチン）

--

ここまで読むと、もはやネットで述べられている Clean Architecture についての深い解説はないのではないかと気づく。実際そうである。

Clean Architecture というアーキテクチャを知る前に、まずは頭のなかにぼんやりあったソフトウェアアーキテクチャとはなにかを再構築しなければいけない。本書には、ソフトウェアアーキテクチャについて次のとおり述べている。

ソフトウェアシステムのアーキテクチャは、それを構築した人がシステムに与えた「形状」である

「形状」を「型」あるいは「枠組み」「フレームワーク」などと読み替えてもよいだろうか。（そろそろ原著を読みたくなってくるがいったん横においておこう）

アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。

これは「ソフトウェアアーキテクチャの目的」と捉えても差し支えないだろう。本書は、それを実現するための方法として次のように述べる。

それらを容易にするための戦略は、できるだけ長い間、できるだけ多くの選択肢を残すことである。

よくわからない。決定をしてはけないということなのか？ビジネスではよく先延ばしするなと聞くが、先延ばしせよといっているのか？

この言葉はみなさんを驚かせたかもしれない

ええ、大変に驚いている。

みなさんは、アーキテクチャの目的を「システムを適切に動作させること」だと考えていたのではないだろうか？

たしかにそうおもっていた節がある。本書では、アーキテクチャというのは動作や振る舞いを決めるものではないという。

言われてみればフレームワークのようなものであるべきで、例えば 「Rails を使うとこの機能は動作できない」ということはない。アーキテクチャというのは実装する機能や振る舞いとは異なる次元に存在するべきなのだ。

そして本書は、アーキテクチャを設計する人、つまりアーキテクトに求められる役割について次のように述べる。

優れたアーキテクトは、方針と詳細を慎重に区別して、方針が詳細を把握することなく、決して依存することがないように、両者を切り離す。優れたアーキテクトは、詳細の決定をできるだけ延期・留保できるように、方針をデザインする。

--

というあたりで、アドベントカレンダー向け記事としてとりとめのない内容になってきたのと、改めて読み返しても理解しがたい部分でてきたので続きはまた次回にします。ちなみに、ここまでで本書の40%です。残り60％！