「ちょうぜつソフトウェア設計入門」第1章 クリーンアーキテクチャ まとめと感想

ソフトウェア設計

本書について

ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用

技術書「ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用」レビューとまとめ。Bobおじさん本を読む前の準備として最適な一冊。からリンク。

第1章 クリーンアーキテクチャ

1-1 ソフトウェアとアーキテクチャ
1-2 アーキテクチャは動作に貢献しない
1-3 汚い設計はなぜ生産性を落とすか
1-4 凝集度
1-5 依存の向きと安定度
1-6 どうすればクリーンになるのか
1-7 偏在するクリーンアーキテクチャ

クリーンアーキテクチャから始まる斬新な順序。しかし、確かに著者の方があえて一般的な本とは逆順にしたと言っていた通り、大域的な説明から始まったほうが全体を俯瞰できるのでわかりやすいと思う。

何をどう配置するか具体的に決まっている技術の使い方とは異なり、独自に開発するソフトウェアのアーキテクチャは人間の事情で変わってきます。なので、各自がオリジナルで設計せざるを得ないのは宿命づけられているのです。クリーンアーキテクチャの目的は(それ以外でもソフトウェアアーキテクチャはみんな)、この多様な独自設計を最小労力で維持するコツを一般化することです。

良い引き込み方。なるほど、じゃあクリーンにどう構築できるんだ?と、続きが読みたくなる。 ソフトウェアアーキテクチャとは何か?何のためのものかということについて、簡単な言葉で説明がある。

良いアーキテクチャとは、ソフトウェアそのもののパフォーマンスではなく、ソフトウェアを開発するパフォーマンスを向上させるもの。不具合が起きても、速く安全に修理できる。今ある機能はそのまま使いつつ成長させることができる。作りかけの場合でも開発中にうまく動いた部分を削除して修正する必要がなくなる。

汚い設計は生産性を落とす。意味を認識するのに時間がかかる。汚い設計の特徴は、

  • まとまりが悪く、あちこち変更しないといけないので苦労する
  • 同じところに意味の違うものが混ざっていて壊れやすい

少しでもコードに変更が入った場合、本当に悪影響がないか確認する手間もあるが、もっと早い段階で現れるのは、どんな影響があるかを認識するための思考負荷が高まること。結果的に、変更箇所が多すぎて考えきれなくなったプログラマーは、諦めて差分だけ差し込んで新たな動きを提供しようとする。そうして、どんどんソースコードが難解になっていく。

ここはまさにその通りで、自分も最初の頃はそうだったと思う。また全然実務ができない人は、動いているコードには一切触るなとソフトウェアエンジニアらしからぬことを言ってくることもあった。そうやって差分だけを挿入して意味のわからないプログラムが出来上がる、という反面教師期間を経験した。

実際に影響がないかではなく、影響がある可能性がゼロだと言い切れることが重要です。

良いことが書かれている。思考負荷をできるだけ小さくすることが生産性を上げる重要な要素であることは痛感している。

依存するものが変わりにくければ、その影響を受けて変更を強いられる可能性が減る。変わりにくい(安定度の高い)ものに依存するのが良い。基本的にアプリケーションの本質部分が安定度が高い。ライブラリやUIなどの技術的手段は非本質。アプリケーションの本質であれば、変更依頼する側にもそれなりの覚悟が必要で、影響度も大きいため、比較的変更されにくい。

クリーンな設計は、

  • ひとつの関心がひとつの箇所に閉じている
  • 利用する/されるの関係箇所を可能な限り減らす
  • できるだけ変更頻度の高い事情に依存しない

クリーンアーキテクチャは、最後の三番目の重要性に着目する。クリーンアーキテクチャは、決まったものではなく、大まかに次の4つに分けられ、上のレイヤーに依存していく(同心円状で、内側に向かって依存していく構造)。

  • ドメインモデル
    誰にとっても必要な事実だけを集めた本質部分。標準ライブラリ以外何にも依存しない。
  • ユースケース
    ユーザーが行いたい操作を表現するロジック。ユーザー要望で変化するが、技術的な理由で変更はされない。
  • インターフェースアダプター
    アプリケーションの枠組み。コントローラやメインルーチン。
  • インフラストラクチャ
    動作の実体。 データベース接続やメール送信等、それぞれ独立したモジュール群。技術の事情に左右されて不安定。

アプリケーションの実動作は、4層目がすべて担う。しかし、3層目は4層目に依存しないとダメなのでは?と思ってしまう。しかし、オブジェクト指向を使うことで、依存方向を自由に制御できるようになる。これが核心。

もちろん、ドメインモデルを中心とする必要は必ずしもないし、クリーンアーキテクチャ自身も層が4つとは限らない。

開発者が身につけるべき本当の力は、クリーンアーキテクチャを通じて理解を深めたオブジェクト指向設計のスキルにあらわれてきます。

これは、GoFのデザインパターンを学ぶことで、オブジェクト指向の本質を理解することができるということと同じことだと思う。デザインパターンは、今では古いとか使ったことがないとか色々と言われているが、依存性の逆転等、様々な原理・原則を学ぶ上ではかなり良い題材と思っている。そうした背景となる知識を得ることで、本当のオブジェクト指向を身につけられると思っている。パターンを丸暗記する意味はほぼ無いと思う。このちょうぜつ本は、クリーンアーキテクチャで、そのオブジェクト指向の本質を学ばせてくれるものなのだと思う。

デザインパターンを通してオブジェクト指向の3大要素「継承」「カプセル化」「ポリモーフィズム」を学ぶには、個人的にはHead First デザインパターン 第2版が非常に良い本だったと思う。この本を読んだら、ぜひ読んでみてほしい。残念ながら、Kindle版は英語しかないらしいが、スタイル的にKindleだと読みにくいと思うので本が良いと思う。

コメント

タイトルとURLをコピーしました