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

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

執筆時点では、ここから先のアドベントカレンダーが埋まっていません！

ぜひ岩手県立大学にゆかりのある方からの参加をお待ちしています。

さて、前回の続きを述べていきます。引き続き、引用ベースと僕のコメント・感想を付け加えています。とりとめの無い内容です。

==

「OOとは何か？」この質問には、多くの意見と多くの答えがある。だが、ソフトウェアアーキテクトにとって、その答えは明らかだ。OOとは「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」である。

OO（オブジェクト指向プログラミング）とはなにか？たしかに僕のまわりでもよく聞く種類のプログラミング議論のひとつだ。多くの場合、「継承」「カプセル化」そして「ポリモーフィズム」の3つが挙がる。

筆者は、C言語のコードを示しながら、カプセル化はOOの特徴ではないことを示す。続けて「継承」は "便利になったこと" 程度であり、ここまででは優れている根拠にはならないという。そして、明確にOOの特徴は「ポリモーフィズム」があることであるという。もっといえば、OO言語は、バグの温床である関数ポインタを言語・パラダイムレベルで隠蔽できていること自体がよさであるという。

なにか言いくるめられている気もするが、普段からとっても高級なプログラミング言語しか利用しておらず、反論するほどの知識と経験を持ち合わせていない...

== 

コンポーネントをどの単位でまとめるか？というトピックである。REP / CCP / CRP の詳細については本に譲るが、これらは相反関係にある。優れたアーキテクトは、この三角形のなかで開発チームが見合った落としどころをみつけるという。例えば、プロジェクトの初期であれば、ソースコードの再利用や安定したリリースを捨ててもよい。徐々に成熟してくると、再利用性を高めるが、それは変更による影響が広範囲になることを意味し、一度のリリースに必要な関心事・工数が増えることになる。

個人的には、テンション図（というのをこの本で知った）というのが好きです。DBMSだとCAP定理や、プロジェクトマネジメントでいうQCDのように、3つある要素のうち2つの達成はできるが3つの達成は困難であるというものですね。いろんな課題や問いには明確な答えというものを欲しがるもののですが、多くの場合は「ケースバイケース」であり、「トレードオフ」なんですよね。逆に「これは確実！」「間違いない」というような主張や方法論は疑ってかかったほうがいいですね。例えば、「時代はクリーンアーキテクチャだから、これ使っておくと開発が楽らしいですよ！いますぐ導入しましょう！」なんていう万能感を出す言い方をされたときは追加の調査が必要でしょう。

==

明らかに重複していたコードが異なる進化をとげ、数年後には両者がまるで違ったものになっていることもある。これは本物の重複ではない。

アーキテクトは、つい抽象化、再利用をする衝動にかられてしまう。だが、必ずしもそれが適切でない場面も多い。ではどうすればよいのか？

その答えは「プロジェクトの初期段階では判断が難しい」である。

選択肢としては、ソースレベル、デプロイレベル、サービスレベルの3つ示している。これもまた一長一短あるので、プロジェクトフェーズに合わせて適切に進めていけという。

==

21章、叫ぶアーキテクチャは、章全体が著者の思想を大きく感じられるものである。一言でいえば、人々はフレームワークに依存しすぎだと主張している。

アーキテクチャはフレームワークから提供されるものではない。フレームワークは使用するツールであり、アーキテクチャが従うものではない。あなたのアーキテクチャがフレームワークにもとづいているのなら、そのアーキテクチャはユースケースにもとづくことはできない。

優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題無く説明できる。

建築家の最大の関心事は、家がレンガで作られていることではなく、家が使用可能であることだ。

フレームワークは非常に強力で、非常に便利なものである。（中略）フレームワークに関する書籍の著者たちも、熱狂的な信者であることが多い。彼らは、フレームワークの使い方を教えてくれるが、フレームワークがすべてを包括し、すべてに行き渡り、すべてのことをフレームワークに任せるという立場を前提としているようだ。

そんな立場になりたいわけではないだろう。

冷静にフレームワークをみてほしい。疑いのまなざしでみてみよう。確かに便利そうだ。だが、コストは？どのように使うべきか、どのように自分自身を守るべきか自問してほしい。ユースケースを重視したアーキテクチャをどのように維持するか考えてほしい。フレームワークにアーキテクチャを乗っ取られないように、戦略をうまく策定しよう。

これらは全面的に賛同できるものではないが、概ね僕も感じていたフレームワークに関する疑念に近い。例えば、あるフレームワークでは、○○-Way あるいは △△モデル・パターンのようなそのフレームワーク特有のワードがある。「それを使っていないor知らないと、にわかではないか？」という雰囲気すら漂わせるものもある。なぜ情報工学用語ではなく特定のツールでしか使えない言葉を使うのだろうと感じていたが明確に反論できる主張はできていなかった。この本ではそこに挑んでいる。

ソフトウェアは、それ単体では価値をうまず、人が利用する「情報システム」の一部であることを忘れてはいけない。そうすると、特定のフレームワーク前提の発想は危険である。著者がいうように、冷静になって「ソフトウェアはビジネスを支えるもの」という視点で進めれば、ビジネスが特定のフレームワークやライブラリに依存すべきではなく、ビジネスをユースケースに落とし込み、それを支える技術・ツール・アルゴリズムという関係になるべきである。

==

今日で本全体を取り扱おうとおもっていましたが時間が足りませんでした。また次回に続きます。