Zenn
📗

もくもく読書会 アウトプット ちょうぜつソフトウェア設計入門

に公開
tech

ちょうぜつソフトウェア設計入門

モチベーション

  • 副業で PHP 触る機会が出てきたので勉強 -> ほぼ使わなくなった
  • 目次の 7 章:依存性注入に引かれた(あまり触れている書籍がないイメージ)

(1) 2023/12/26 20:24

  • 読み進めた範囲：6P まで (漫画も含む)
  • 印象に残った箇所:クリーンアーキテクチャの目的は、多様な独自設計を最少労力で維持するコツである
  • 良かった点:イラストは可愛いが、内容は可愛く無い(濃い)
  • 気になった点:表紙からは初心者向けに見えるが設計に関する内容なので抽象度が高め、序盤(1 章)は具体的なコードが出てこない、PHP の入門には向かない

(2) 2024/01/23 20:26

  • 今日読み進めた範囲：7 章〜
  • 書いてあった内容：依存性注入（DI）に関する説明
  • 印象に残った箇所:内部でインスタンスを生成するモジュールから生成処理を追い出して責務を分離する工程を実際のコードで説明されていた。ここで電子工作で各部品は各メーカが保証するのと、それをどう集めて組み立てるのは別の問題という例えがわかりやすかった。
  • 良かった点:実際のコード+ディレクトリ（Package)構造がわかる
  • 反省：いきなり 7 章に飛ぶべきではなかった...

(3) 2024/02/27 20:28

  • 今日読み進めた範囲：第 1 章 クリーンアーキテクチャ
  • 書いてあった内容：汚い設計の特徴について。どうすればクリーンになるか。
  • 印象に残った箇所：汚い設計がされているコードへの変更に対してのイラスト「勝手に動かしたらダメそうだし、そのままにしてとりあえず見えるところに置いておこう」
    良かった点：内容は難しいけどそれでも分かりやすく書こうとしているのが伝わる.イラストが息抜きになる。設計の答えは盲目的に従って正しいと言えるものではないというのはなるほど、と思った。ChatGPT くんに聞いて答えが出るものでは無い。

話した内容

クリーンアーキテクチャの概念図、ドメイン、ユースケース、インターフェースあたりの話は初見だとわかりにくくなかったか？

ドメイン、ユースケースまでは本屋の例えがわかりやすかった。

  • 仕入れや販売->ドメイン
  • 効率的な仕入れ操作、売った金額の管理->ユースケース

インターフェース、アプリケーションのところは理解が浅いが、
それぞれ筆者が一言で表現しまとめているのでイメージできたつもりになれた。

だが、上記は非常に簡単なケース。実際はもっと複雑な現実をドメイン、ユースケースに置き換えなければならない。しっかりやろうとしたらメンバー間で衝突するシーンが増えそう。「どこまでがドメインで〜どこまでがユースケースで〜」と人によって境界線が異なる。

例えば"安定度"という言葉が出てきていて、これはコードの代わりにくさを表す度合いで、できる限り"安定度"の高いコードに依存すべきと書かれている。安定度については、サービスの理解度やオーナー要求傾向の把握といった面も影響しそうな部分で、その違いがそのまま安定度の認識の違いに表れそう。完全予測は無理。

クリーンアーキテクチャは AI に聞いても絶対的な設計の答えが返ってくるものでは無い。
クリーンアーキテクチャが絶対正しいというよりも、汚い設計にしないための考え方という捉え方がしっくりくる。
汚い設計にすべきで無いことは明白なので、まずは頭の片隅におきつつ、実際の設計、コーディング時に汚くならないように努めるしかなさそう。

(4) 2024/03/26

  • 今日読み進めた範囲：第 2 章 パッケージ原則
  • 書いてあった内容：複数のコードをどうまとめて再利用するかを考えるときに用いる原則について。次のオブジェクト指向の章における事前知識という建て付けっぽい。
  • 印象に残った箇所：パッケージリリース=チーム開発の場合では main マージ。リリースと再利用の一致。
    現プロジェクトの黎明期に、再利用される想定のコンポーネントを作る際は、他の人がすぐ使いまわせるように、そのコンポーネントだけで閉じた PR にすべきだ！という話をしたことを思い出し。
  • 良かった点：聞き馴染みの無い専門用語を知れた(REP,CRP,CCP)

再利用/リリース等価の原則

REP(再利用・リリース等価の法則)
Reuse/Release Equivalence Principle

  • リリースされたものだけを再利用。
  • 再利用させたければリリースする。

ソースには固有処理と再利用可能な一般的な処理が混ざっている。
再利用可能な部分を切り出せばプロジェクト内での各部から共有できる。
クリーンアーキテクチャのドメイン部は最も再利用生が高い要素と言える。

リリースと再利用の一致

  • うまく平行開発を進めるために、パッケージわけが必要。
  • リリース待ちがネックにならないようにする。

再利用単位を見極めるポイント

  • CRP(全再利用の原則)
  • CCP(閉鎖性共通の原則)

CRP ではこの変更は必要だけど、この変更は採用したくないという取捨選択ができないことを強調している。

(4) 2024/03/26

  • 今日読み進めた範囲：第 2 章 パッケージ原則
  • 書いてあった内容：1.分けられるものは分けましょう。利用しやすいパッケージにわけたり、責務でわけたり。2.まとめられるものはまとめましょう。まとまってないと変更が波及して大変になる 3.循環依存を避けましょう、依存関係にあるのものはパッケージの中に閉じる。
  • 印象に残った箇所：わかれているものを後で混ぜるのは簡単だが、混ざっているものを分け直すのは困難。つながりがわかりにくくなる。
  • 良かった点：挿絵がかわいい
  • 難しいと思った点：イラストで噛み砕いて説明しようとするあまり意図を汲み取るのが難解(むしろ深く考えたら負けかもしれない...)

全再利用の原則 Common Reuse Principle

ひとつのパッケージに起きた変更は、全て利用するか全く利用しないかのどちらか 2 択。パッケージ利用者に取捨選択はできない。

閉鎖性共通の原則 Common Closure Principle

一つの変更が必要なとき、一つのパッケージ内の変更にとどまるような形にする。単一責任の原則にちかい。

(5) 2024/04/23

  • 今日読み進めた範囲：第 2 章 パッケージ原則 前半
  • 書いてあった内容：1.分けられるものは分けましょう。利用しやすいパッケージにわける、責務でわける。2.まとめられるものはまとめましょう。3.循環依存を避けましょう、依存関係にあるのものはパッケージの中に閉じる
  • 印象に残った箇所：わかれているものを後で混ぜるのは簡単だが、混ざっているものを分け直すのは困難。つながりがわかりにくくなる。
  • 良かった点：挿絵がかわいい
  • 難しいと思った点：イラストで噛み砕いて説明しようとするあまり意図を汲み取るのが難解(むしろ深く考えたら負けかもしれない...)

(6) 2024/05/28

  • 今日読み進めた範囲：第 2 章 パッケージ原則 後半
  • 書いてあった内容：
    • 安定度、抽象度等価の法則。安定度、抽象度は相関関係にある
    • 安定度が高いパッケージは、抽象度も高い。
  • 印象に残った箇所：
    • 抽象度の高いパッケージに依存して、ちょっとずつ具象化を進めていくと、無駄のないアーキテクチャができあがる。
      • この「ちょっとずつ」の匙加減が難しいと感じる。
      • 抽象度が高すぎると、ただ橋渡しするだけの関数が多くなりコードが追いにくくなる気がした。
    • ライブラリやフレームワークに依存すると不安定になるという勘違いがあるが、クリーンアーキテクチャの外の話で実務のコードよりも安定している。
      • 脆弱性が出るといった不安定さはあるが、実務よりは安定してるかも。
  • 良かった点：挿絵がかわいい
  • 悪かった点：2 章まででコードが無い... チラ見すると 3 章からはありそう。

話したこと

(7) 2024/07/23

  • 今日読み進めた範囲：第 3 章
  • 書いてあった内容：
    • 多様性：ずばりプラグイン、同じ方法で扱うことができる。
    • 多様性と型システムは独立した概念
    • ダックタイピング
      • インターフェースを宣言し実装してなくとも、インタフェースの持つメソッドを全て持っているなら、呼び出し側で同じものとみなす
  • 良かった点：雰囲気は掴める?
  • わかりにくい点：多様性の説明があっさり。

(8) 2024/08/27

  • 今日読み進めた範囲：第 3 章 継承、汎化
  • 印象に残った内容：
    • 継承は効率的な差分プログラミングを意味する概念ではない
    • オブジェクト継承の醍醐味は extends ではなく概念の一般化と実
      装の分離
  • 良かった点：３章からはコード例が増えてきた
  • 専門用語がごちゃついてきて整理ができず、よくわからんとなりがち。もっとイラスト多めだと嬉しい。

(9) 2024/09/24

  • 今日読み進めた範囲：第 3 章 継承、汎化
  • 書いてあった内容：
    • 良い抽象は後から気づく
    • 具象化された例を見て一般化を考える
    • 現実のバリエーションから抽象化を考えることを汎化という
    • はじめから抽象化を考えると無限に関係ないものまで考えてしまう
      • ペットショップで扱うCatなのに、Catから考えると野良猫についての可能性を考えてしまう
        • ペットショップなのに飼い猫以外のことを考えはじめると全く別システムになってしまう
    • スマートな抽象が見つかると、パッケージを完結させリリースできる
    • 安定依存の原則の方向付けに役立つ
      • 安定=変更の起こりにくさ
      • これがわかれば安定度抽象度等価の法則との関係性が掴めてくる
    • 抽象と具象は1対多でなくても良い
      • パッケージ視点で考えると、それだけでリリースできる
  • 良かった点：2章でさらっと紹介した安定依存の原則について深掘りされていた

(10) 2024/10/22

  • 今日読み進めた範囲：第 3 章 継承、汎化
  • 書いてあった内容：
    • 多態性(ポリモーフィズム)は多でなくても役にたつ
    • 依存の観点からは抽象と具象は1対多である必要はない
    • 1:1で多態性のバリエーションがなくても安定度確保の観点からは役立つ
    • 1:1でも先に抽象パッケージを安定させることができる
  • 印象に残った箇所：
    • 具象がなくてもパッケージは成り立つ
    • 直接依存させると詳細まで完成させないといけないが、仮でインターフェースに依存させておけば一旦安定したパッケージにできる
GitHubで編集を提案

Discussion