SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。 でもテーマが定まってない感がすごい。

『Clean Architecture』を読んだ

『Clean Architecture』読みました。電子書籍で購入しました。

honto.jp

学ぶところもありつつ、そうでもないよなぁという部分もありつつ、という感じでした。個人的には、確かにそうよねと思える部分が多く、原理原則を学ぶ本としていい感じだと思いました。

手段にはそこまで言及していない、ということを念頭に置くとよいです。

そんなわけで、感想をば。

訳者さんのコメントから

訳者あとがきに、

フレームワークから着手しないことが本当に正しいことなのかは、私にはまだよくわからない。

(中略)

正直、大昔の話を何度もされても困るのだが(翻訳も大変だし)、それでも「時代を超越した不変のルール」が存在するとして、著者はいつまでも原理・原則に忠実であろうとする。

という記述がある通り、訳者さんであっても疑問を呈する部分はあるので、読んだ人それぞれで思うことはいっぱいある本だと思います。

本書構成

付録を除いて全34章です。

基本、ソースコードは載っていません。大事なことなのでもう一度。ソース例はほぼありません。

図はわりと載っているので、UMLは見たら分かるぐらいの知識はあったほうが楽に読めると思います。

第Ⅲ部は、SOLID原則について述べた章です。

第Ⅳ部は、さらにそれを発展させて、コンポーネントの凝集性、結合の各種原則について述べています。

それを発展させ、アーキテクチャとは何かについて述べたのが第Ⅴ部です。

第Ⅶ部が、訳者さんもおっしゃっていた大昔の話と思われます。確かに大昔でした。

言いたいこと

私が思う、筆者の主張はこのようなものです。

詳細に依存しない

第Ⅵ部の「詳細」は、詳細とは何ぞやについて書いてあります。

特にビジネスルールを詳細部分に埋め込むことを、全力で避けるべきという主張がありました。

もっとも、筆者のいう「詳細」は

と、多岐にわたります。

データベースが詳細という主張は、様々な場所でなされているので、省略します。

ウェブが詳細、という部分は、GUIは詳細であり、ウェブはGUIであるという事実からくるものです。

ウェブは入出力デバイスの一種であると考えるとよいとのこと。

結局、ウェブを使ったとしても、計算のパワーをサーバーに集約するか端末に分散させるかの振り子を行ったり来たりしている*1との主張です。

フレームワークが詳細というのは、細かい主張は本書を読むのが良いと思いますが、どっぷり依存することを避けるべきだ、ということです。

避けられない場合はある*2が、気軽に決めるな、決めたからには覚悟して付き従え、とのことです。

臭いを感じ取るのがアーキテクトの仕事

コードの臭いというか、アーキテクチャの臭いというか、これまずくない?というのを感じ取るのがアーキテクトの仕事です。

YAGNIという原則があります。

ja.wikipedia.org

You ain't gonna need it

の頭文字をとったもので、「あとで必要になることはない」とか「そんなの必要ないって」といった感じで訳されます。

設計関連でいうと、拙速な抽象化を避けるように、という意味で使われます。

このYAGNIの原則を破る判断こそ、アーキテクトが行うべきとのことです。

筆者曰く、

我々アーキテクトは、それ*3がいつ必要になるか気を配らなければいけない。また、境界を完全に構築しようとすると、コストが高くつくことを認識する必要がある。それと同時に、境界を無視すると、たとえ完全なテストスイートやリファクタリングの規律があったとしても、レイヤーを追加するコストが非常に高くなることも認識する必要がある。

(中略)

ソフトウェアアーキテクトは未来に目を向けなければいけない。頭を使って推測するべきだ。

(中略)

しかもこれは、1回限りの決定ではない。(中略)常に見張る必要がある。

とのこと。

私も、設計はプロジェクト開始時一回限りで終わるという考えは捨てているので、この考え方には全面的に同意しています。

プロダクトを作るなら、継続性は当然考慮すべきで、その継続性の確保のためにシステムの柔軟な設計も必要となると思います。そのとき必要となるのがソフトウェアアーキテクトです。最初に一回設計したら終わり、なんてことは普通はあり得ません。

好きな部分

私が、本書で好きな言葉等を挙げます。

なお、SOLID原則については一応把握しているため、そこは流し読みしているのでご了承ください。

第13章 コンポーネントの凝集性

再利用の単位とリリースの単位は等価になる。(再利用・リリース等価の原則)

同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更理由やタイミングが異なるクラスは、別のコンポーネントに分けること。(閉鎖性共通の原則)

コンポーネントのユーザーに対して、実際には使わないものへの依存を強要してはいけない。(全再利用の原則)

コンポーネントとは、DLLみたいなものと思ってください。

コンポーネントの凝集性について、3つの原則があります。これらは相反する部分があるため、どのような凝集性にするか、という点はアーキテクトが決める必要があるとのことです。

詳細は本書を読んでいただくことをお勧めします。

第15章 アーキテクチャとは?

そもそもソフトウェアアーキテクトはプログラマである。プログラマを続けておかなければいけない。

こういうことを主張する本は好きです。プログラミングできないと、設計上の勘は鈍っていきます。それに、設計した結果はたいていの場合プログラムで表現されるので、プログラムを考慮しない設計はありえません。

第16章 独立性

優れたアーキテクチャがあれば、選択肢を残すことでそれが容易になる

「それ」は「システムを変更せざるを得なかった場合のシステム変更」のことを指します。選択肢を残しておく、という部分での記述です。

設計を取り換えられるようにしておくのは、オープン・クローズドの原則が一部噛む部分です。

第29章 クリーン組込みアーキテクチャ

1.まずは、動作させる。動作しなければ、仕事にならない。

2.それから、正しくする。あなたやほかの人たちが理解できるようにコードをリファクタリングして、ニーズの変化や理解の向上のためにコードを進化させていく。

3.それから、高速化する。「必要とされる」パフォーマンスのためにコードをリファクタリングする。

(中略)

ほとんどのアプリケーションは、ただ動作するためだけに作られており、長寿となるように正しくコードを作ることはほとんど考慮されていない。

(中略)

アプリを動作させることだけに関心を持つプログラマ(組込みプログラマかどうかを問わない)は、プロダクトや雇用主に不利益を与えている。プログラミングとは、アプリをただ動作させる以上のものなのだ。

…耳が痛いです。開発する時は、後先考えて作っているつもりでも、本当にそうなっているか、自信がないときがあります。

最初期はしょうがなくても、ただ動かすためにアプリケーションを作らない。これは肝に銘じて日々自分に言い聞かせなければならないです。

第34章 書き残したこと

付録の前の、最後の文章です。

いくらうまい設計をしても、その実装方法の複雑さを考慮しなければ、あっという間に設計が崩れてしまう。

(中略)

使える選択肢は可能な限り残しておきたいが、理想に走りすぎてもいけない。

チーム規模、メンバーのスキル、予算等、様々な状況を考慮して、設計は決めるべきとのことです。

たしかに、「予算が湯水のようにあり、使える時間も無限で、いつリリースしても間違いなくビジネスは大成功する」なら、理想を追い求めて問題ありませんが、現実にそんなうまい状況は無いです。

そのとき、正しく取捨選択するのもまた、アーキテクトの仕事だろうと思いました。間違った方向に判断して、そのビジネスを閉ざしてしまうことだってあり得ます。

そう考えると、責任は重いですね。でも、だからこそ勉強を止めてはならないと、自分を奮い立たせる元となります。

全体感想

Webフレームワークは詳細である

とし、Webフレームワークへの依存を否定している本書ですが、私も実際に設計とアプリ作成をしている中でフレームワークのつくりから逸脱できないと思ったことはあります。

Djangoを使っていて、中核となるオブジェクトが判明したとき、各サイトから共通で参照できる場所にソースを置きたいと考えました。

そうなると、アプリという単位でサイト単体で動くようにしている(気がする)Djangoとはかみ合わない部分となってしまうようで、共通部分を作るのをためらったことがあります。

結局どうすればよかったのだろうと、今でも思います。

Webフレームワークを詳細と扱い、依存外に置く方法は本書では簡単にしか示されていないので、これからも考える必要があると思っています。


本書では直接触れられていませんが、設計は問題を自分の制御下に置くために行うものだと思っています。現実の複雑さを落とし込み、管理できる状態にする作業が設計であり、それを表現する手段がプログラミングです。

SOLID原則などのプラクティスを利用し、依存関係等を制御できるようになると、複雑さに立ち向かえるようになります。それによって、ソフトウェアはより価値のあるものになるのでは、と思います。

SOLID原則等のソース例を見たい

本書では、前述の通り、ほとんどソース例が記載されていません。

以下のような本であれば、SOLID原則や、本書で触れられたヘキサゴナルアーキテクチャの説明があります。そちらを合わせて読むと、より理解が進みます。

SOLID原則

私のブログ記事になります。詳細はそちらを。今ならAdaptive Codeが良いです。

hiroronn.hatenablog.jp

hiroronn.hatenablog.jp

ヘキサゴナルアーキテクチャ

honto.jp

ドメイン駆動設計を実践するうえで、ヘキサゴナルアーキテクチャを適用したものが出てきます。

これはソースがGitHubに上がっていた気がしますが、探しきれなかったので見つけたら貼ります。

おわりに

賛否両論ある本だと思います。私は好きです。

ソフトウェアのアーキテクチャは、こういう部分を考慮しておくべきだ!ということがずっと書かれています。ソース例がほとんど無いので、すぐ実践で役立つものではない、ということは念頭に置いておくとよいと思いました。

実践的なものを期待すると落胆します。

内容も簡単ではなく、まだまだ勉強が足りないな、と感じさせる一冊でした。

*1:ブラウザでアプレットを動かすと思ったら、動的コンテンツをサーバーに戻し、Web2.0ではJavaScript等でブラウザ側で動的制御を行い、Node.jsでJavaScriptをサーバーに戻したり、といった一連の動き

*2:Javaだったら標準ライブラリとか

*3:アーキテクチャの境界