[技術書籍レビュー] Clean Architecture

以前読んだ「手を動かしてわかる クリーンアーキテクチャ」ではなく、 原初だと思われる「Clean Architecture」を読んでみました。 プログラミングを極めようとすると、アーキテクチャを学ばなければいけません。 初心者 -> 中級者 ここまでは、仕事をしていれば、ある程度は達成できますが、 ここから上級者になるためには、アーキテクチャを理解しなければいけないということが、 この本を読んで、すこ〜しわかったよーなわからないような・・・ でも、雰囲気的に良書であることは事前になんとなくわかったので、そりゃあ読まないわけにはいかないでしょう。

レビュー

★★★☆☆

やっぱり英語訳の技術書って、読むのがしんどいですね。 別に英語の原書を読んでいるわけではないのですが、訳してあるので、英語の言い回しだったり、 真剣に書いてある文章だと思ったた、アメリカンジョークだったり・・・ ノリが圧倒的に、海外雰囲気なので、そういうのが毎回疲れるんですよね。 あと、例え話が基本的によくわからない（これはアルアルでしょう） 日本語の技術書でもなかなか、分かりにくいし、コードをそのまま載せられても・・・という感じなので、 コードの説明が、まあまあなウェイトを占めているこの書籍は、気合を入れないと、 中級者の人が読むのもなかなかしんどいと思いますね。 ただ、レビュー点が中間ぐらいだったのは、際立って良かったところと、全然刺さらなかったところが半々ぐらいだったという意味で、辛口甘口も合わせて中間評価にしました。 正直、読み終わった後で、「読んで良かった」という意識はありました。 本って、ちょっとでもつまらない箇所があったら「つまらない本」と考える人もいるみたいですが、 個人的には、その中で、1つでも自分の学習につながったり、スキルアップできる箇所があるだけで、 読んで良かった評価になると思うんですよね。 もちろん、1つも読んで良かったと思わない書籍もありますよそりゃあ。 でも、とにかく、 「書いている人のパーソナリティ的なことを理解してよむと、技術書は比較的読みやすくなる」 というのも、この本でよくわかった点でした。

この書籍の学びポイント

ソフトウェアアーキテクチャの目的

求められるシステムを構築・保守するために、必要な人材を最小限に抑えること。

設計の品質

顧客のニーズを満たすために必要な労力で計測をする。 システムのライフタイム全体で、低く保たれていれば、その設計は優れている。 逆にリリースごとに、労力が増えるなら、その設計は優れていない。

・リリースのために事前に検討するための時間 ・リリースにかかる時間。 ・リリース後のエラー数。

経営者は、これらで品質を考えるといいでしょう

間違った設計

イソップの「ウサギとカメ」という物語からの教訓

・遅くとも着実であれば競争に勝つ ・競争は短期戦ではない、強いものが勝つわけでもない。 ・急げば急ぐほど速度は落ちる

とにかく、崩壊したコードを書く方が、クリーンなコードを書くよりもとにかく常に遅いのだそうです。

ソフトウェアの提供する価値

全てのソフトウェアは、ステークホルダーに2つの異なる価値を提供する。 それは「振る舞い」と「構造（アーキテクチャ）」である。 でも、残念なことに、どちらかにフォーカスされることの方が多い。 そして、残念なことに、より価値の低い方にフォーカスされることが多く、最終的にソフトウェアの価値がゼロになってしまうことがある。 振る舞い ソフトウェアが、お金を生み出したり、節約できるようにソフトウェアが動くこと、操作できること、 これらそのものが「ソフトウェアの振る舞い」です。 この振る舞いには、仕様や設計があり、それらをプログラミングして、エラーがあれば、修正する。 プログラマーは、これらを仕事としていると考えている人が大半で、これが大きな間違いだとこの書籍では指摘している。 構造 ソフトウェアは、「ソフト」でなければいけないと書かれている。 ハードウェアは、固定された強固なもので、変更がハードなのだが、 ソフトウェアは、簡単に変更できることが前提であることを忘れてはいけません。 ロンチした後でも、機能追加や、仕様変更、別のシステムとの繋ぎこみなど、 ソフトウェアは、どんどん進化して作り直して、書き足して、生き物のように成長していくのが本来の姿である。 でも、多くのプログラマーは、仕様にないことは「できない」と言い張るし、 予定されていない変更は、「聞いてない」と作業をしたがらない。 本当は、それらを考慮して構造を組んでおく必要がある。

アイゼンハワーマトリクス

ドワイト・D・アイゼンハワー大統領による、「重要度と緊急度のマトリックス」 このマトリックスは、以下の4つの優先順位をつけることができる。

1. 緊急かつ重要 2. 緊急ではないが重要 3. 緊急だが重要ではない 4. 緊急でも重要でもない

コードのアーキテクチャは「1と2」、 コードの振る舞いは「1と3」に位置する。

ソフトウェアアーキテクチャのジレンマ

ビジネスマネージャーが、アーキテクチャの重要性を評価できないため、ソフトウェア開発者が会社に雇われている。 したがって、ソフトウェア開発チームには、機能の緊急性よりも、アーキテクチャの重要性を強く主張する責任が求められる。 この「責任」を果たすためには、「戦い（闘争）」に足を踏み入れる事を意味する。 開発チームは、企業にとって最善と思われることを求めて闘争する。 ソフトウェアの開発チームも、ステークホルダーも、保護すべきソフトウェアに対する責任がある。 ビジネスロジックを優先して、アーキテクチャを後回しにするということは、役割をは足していないのと同じと言える。

アーキテクチャに重要な3つの要素

・コンポーネントの分類 ・データ管理 ・機能

構造かプログラミング

構造かプログラミングは、直接的な制御の移行に規律を課すものである。 最小の機能から、最大のコンポーネントまで、 あらゆるレベルにおいて、ソフトウェアは反証可能性によって動かされている。 ソフトウェアアーキテクトは、 ・簡単に反証できるモジュール ・コンポーネント ・サービス これらを定義しようとする。 さらに上位のレベルにおいて、構造化プログラミングのような制限を課している。

オブジェクト指向プログラミング

オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すもの。 簡単にいうと「データと関数の組み合わせ」で以下の3つで説明されることがある。

・カプセル化 ・継承 ・ポリモーフィズム

プラグインアーキテクチャという構造により、独立してデプロイすることが可能になる。

関数型プログラミング

関数型プログラミングは、代入に規律を課すもの。 ラムダ計算に基づいているのが特徴。

・普遍性とアーキテクチャ ・可変性の分離 ・イベントソーシング

これらにより、十分な記憶容量と、処理能力があれば、アプリケーションを完全に普遍にできる。 したがって、完全に関数型になる。

設計の原則

・変更に強いこと ・理解しやすいこと ・コンポーネントの基盤として、多くのソフトウェアシステムで利用できること

SRP : Solid Responsibility Principle 単一責任の原則 OCP : Open-Closed Principle オープン・クローズドの原則 LSP : Liscov Subsituation Principle リスコフの置換原則 ISP : Interface Segregation Principal インターフェイス分離の法則 DIP : Dependency Inversion Principle 依存関係逆転の原理 ADP : Acyclic Dependencies Principle 非循環依存関係の原則 CRP : Common Reuse Principle 全再利用の原則 CCP : Common Closure Principle 閉鎖性共通の原則 REP : The Reuse/Release Equivalence Principle 再利用・リリース等化の原則 SDP : Stable Dependencies Principle 安定依存の原則 SAP : Stable Abstractions Principle 安定度・抽象度等化の原則

コンポーネントの原則

コンポーネントとは、デプロイの単位のことである。 リロケータビリティ（再配置可能性）は、スマートローダによって、バイナリコードをメモリに再配置できるようにした。 これによって、プログラマは、関数ライブラリとアプリケーションをどこにロードできるか指示できるようになった。 さらに、リンカによって、プログラムを個別にコンパイルやロードできるセグメントに分割できるようになった。

マーフィーの法則

「プログラムは、コンパイルとリンクに使える時間を使い切るまで肥大化する」

アーキテクチャとは

・開発 ・デプロイ ・運用 ・保守

これらをいかに容易にすることが、アーキテクチャと言える。 そのために、できるだけ多くの選択肢を残しておくことが重要であり、 システムのライフタイムコストを最小限に抑え、 プログラマの生産性を最大にすることである。

あとがき

冒頭から、次のような文章でインストラクションが書かれていた。

プログラムを動かすために膨大な知識とスキルが必要になることはない。高校生だっていつもプログラムを書いている。若い大学生ならPHPやRubyの短いコードを組み合わせ、数十億ドルのビジネスを始めていたりするくらいだ。 Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ; 角 征典; 高木 正弘. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (p. 30). (Function). Kindle Edition.

プログラムを書いたことがない人は少しギョッとするかもしれないが、 学生はもとより、エンジニアではない人がいつもプログラムを書いている環境は、至って不思議ではないという事を知る必要がある。 日本はとにかく、経済先進国と言われているが、IT後進国がひどい現状である国でもある。 そんなプログラムがわからないけど、わかりたいという人は決して少なくないというのも事実なので、ソフトウェアの事を知ることは今後のデジタル未来への自己投資と考えてもいいかもしれませんね。