メインコンテンツまでスキップ

「高凝集・低結合」TypeScript版：17章アウトライン（Windows＋VS Code前提）🪟💻✨

前提：TypeScript初級〜中級／高凝集・低結合は初めて／設計は超入門😊 AI支援（GitHub Copilot / OpenAI Codex等）導入済み前提🤖💡 題材は「小さめのアプリ（ToDo＋締切通知 / サークル備品管理 / 簡易EC）」で統一すると進めやすいよ🎀✅

第1章：AIと仲良く進めるルール（TS版の共通作法）🤖✨​

  • ねらい🎯：AIを便利に使いながら、設計判断は自分でできるようにする
  • 主な内容📚：AIは案出しが得意💡／最終判断は「責務混在🍲」「依存増加🔗」でチェック🧠✅／1章1〜2プロンプト🎀
  • ハンズオン🛠️：AI案を“採用/保留/却下”に分けて理由を書く📝
  • AIプロンプト🤖 1)「このコードの責務を3つに分ける案を、ファイル分割も含めて提案して」 2)「その案、責務の混在やimport依存の増えすぎがない？危険点を3つ」

第2章：変更が怖いTypeScript（あるある地獄）を体験😱➡️😄​

  • ねらい🎯：「なぜ高凝集・低結合が必要か」を体感する
  • 主な内容📚：UI/HTTP/状態/整形が混ざると変更が連鎖する💥／“直したら別が壊れる”原因
  • ハンズオン🛠️：小さな仕様変更をして、壊れた場所と原因をメモ📒
  • AIプロンプト🤖 1)「変更に弱いポイントを5つ、理由つきで指摘して」

第3章：凝集と結合を“ふんわり”理解する🧩📚​

  • ねらい🎯：「良い/悪い」を言葉にできるようになる
  • 主な内容📚：高凝集＝同じ目的でまとまる🎯／低結合＝必要以上に依存しない🔗／結合ゼロは正義じゃない🙅‍♀️
  • ハンズオン🛠️：短い例を見て「凝集高い？結合強い？」クイズ🧠
  • AIプロンプト🤖 1)「この関数（orモジュール）の責務を一文で言うと？」

第4章：設計の判断軸は「変更理由」🧠✨​

  • ねらい🎯：分け方の基準を覚える（“好み分割”を卒業）
  • 主な内容📚：変更理由が同じものをまとめる🧲／UI・業務・外部I/O（HTTP/DB/Storage）を分ける🚪
  • ハンズオン🛠️：要件から「変わりそうな点」を3〜5個書き出し→境界を引く🗺️
  • AIプロンプト🤖 1)「この機能の変更理由を5つ挙げて（UI/業務/I/Oで分類）」

第5章：ニオイ図鑑① “God Module” を見抜く👃💦​

  • ねらい🎯：1ファイル何でも屋（巨大module）を検出できる
  • 主な内容📚：exportが増えすぎ／責務が散らばる／修正が怖い😵‍💫
  • ハンズオン🛠️：巨大ファイルを“責務ラベル”で色分けして分割案を作る🎨
  • AIプロンプト🤖 1)「このファイルを責務でグルーピングして、分割後のファイル名案も出して」

第6章：ニオイ図鑑② “UI×通信×状態×整形”の混在🍲💥​

  • ねらい🎯：フロント/API周りで起きがちな混在を避けられる
  • 主な内容📚：コンポーネント（orハンドラ）が肥大化／非同期処理が絡んで破綻😱
  • ハンズオン🛠️：表示・取得・変換・ルールを箱分け（UI / UseCase / Infra / Mapper）📦
  • AIプロンプト🤖 1)「このコードをUI/業務/通信(I/O)/変換に分類して、混ざってる箇所を指摘して」

第7章：高凝集① “責務で切る”（関数・ファイルの基本）✂️🎯​

  • ねらい🎯：小さくまとまった関数/モジュールを作れる
  • 主な内容📚：1つの関数がやることは1テーマ／同じ理由で変わるものを近くへ🏠
  • ハンズオン🛠️：長い関数を「準備/判断/実行/整形」などで分割して責務を整理🧹
  • AIプロンプト🤖 1)「この関数を責務で分割するとしたら、分割案を3つ出して（メリデメ付き）」

第8章：高凝集② データとルールを近づける（“型で守る”入口）🏷️🧠​

  • ねらい🎯：“ここでしか使わないルール”を適切な場所に置ける
  • 主な内容📚：プリミティブだらけ問題（string/number乱舞）😵／小さなドメイン型の作り方✨
  • ハンズオン🛠️：Email/Price/Deadline みたいな型（＋生成関数）で不正を入口で止める🛡️
  • AIプロンプト🤖 1)「この値（string/number）をドメイン型にするなら、どんな型と生成関数が良い？」

第9章：高凝集③ 命名とフォルダで迷子を防ぐ📁🧭✨​

  • ねらい🎯：読む人が“場所で理解”できる構造になる
  • 主な内容📚：命名＝責務の宣言📛／utils増殖は黄色信号🚦／“置き場所ルール”の作り方
  • ハンズオン🛠️：フォルダとファイル名を責務ベースに整理し、importが自然になるようにする🧩
  • AIプロンプト🤖 1)「この機能に合うフォルダ構成案を3つ（初心者でも迷いにくい順で）」

第10章：低結合の入口 “import依存” を見える化👀🔗​

  • ねらい🎯：結合が強い場所（依存の集中・循環）を見つけられる
  • 主な内容📚：importの矢印が増えると変更が伝染🕸️／循環依存（circular deps）の怖さ😱
  • ハンズオン🛠️：主要モジュールの依存矢印を手描きでOKだから描く✍️➡️
  • AIプロンプト🤖 1)「この構造、循環依存が起きそうな点ある？疑わしい箇所を挙げて」

第11章：低結合① “引数で渡す”から始める（関数DI）🎁✨​

  • ねらい🎯：依存を外から渡して差し替え可能にする第一歩
  • 主な内容📚：関数引数で依存注入（fetch/clock/loggerなど）🔁／“中で作らない”
  • ハンズオン🛠️：Date.now()やfetchを直接呼ばず、引数で受け取る形にする⏰🌐
  • AIプロンプト🤖 1)「この依存を引数で渡す形に直すなら、引数設計はどうする？」

第12章：低結合② “契約”を作る（interface / type の使い分け）📜🔌​

  • ねらい🎯：差し替えの“形”を安定させる
  • 主な内容📚：TSは構造的型付け（形が合えばOK）🧩／interfaceとtypeの使い分け／契約を小さく保つ✨
  • ハンズオン🛠️：外部I/O（API/Storage）を契約で包んで、利用側を守る🛡️
  • AIプロンプト🤖 1)「この契約を小さくするなら、メソッド/型は何を削るべき？」

第13章：低結合③ “組み立て場所”を作る（Composition Root）🏗️✨​

  • ねらい🎯：依存の生成は1箇所に寄せて、中心ロジックを軽くする
  • 主な内容📚：usecaseは依存を受け取るだけ🎀／生成はアプリの入口でやる🚪
  • ハンズオン🛠️：main（or entry）で依存を組み立てて注入する流れを作る✅
  • AIプロンプト🤖 1)「この依存関係だと、組み立てはどこが自然？フォルダ案もお願い」

第14章：TSならでは① “型と実行時は別物”を理解する🧠⚠️​

  • ねらい🎯：「型があるから安全」になりすぎない（落とし穴回避）
  • 主な内容📚：型はビルド後に消える👻／外部入力は実行時検証が必要（例：schema validation）🛡️
  • ハンズオン🛠️：APIレスポンス（未知）→検証→ドメイン型へ変換、の流れを作る🔁
  • AIプロンプト🤖 1)「この入力データ、壊れ方（欠損/型違い）を想定して検証項目を列挙して」

第15章：結合の罠① フラグ引数＆“文字列で指示”問題🚩🔤💦​

  • ねらい🎯：分岐だらけ・仕様が散らばる設計を避ける
  • 主な内容📚：boolean引数で挙動変更＝責務混在🍲／stringly-typed（"admin"みたいな直書き）で事故る😱
  • ハンズオン🛠️：判別可能Union（discriminated union）で安全に分岐する方向へ🧩
  • AIプロンプト🤖 1)「このフラグ分岐、Union設計にするなら型はどう切るのが良い？」

第16章：モジュール境界（公開面を絞る＆importルール）📁🔒✨​

  • ねらい🎯：規模が増えても崩れない“境界ルール”を作る
  • 主な内容📚：公開APIを絞る（入口を少なく）🚪／barrel（index.ts）乱用注意⚠️／循環依存を作らない配置
  • ハンズオン🛠️：各モジュールに“公開ファイル”を決め、他は直接import禁止ルールを作る🧱
  • AIプロンプト🤖 1)「このフォルダ構造、公開面を絞るなら“外から触っていいファイル”はどれ？」

第17章：総まとめミニプロジェクト（設計→実装→最小テスト）💪🎉​

  • ねらい🎯：高凝集・低結合を“自分の手”で再現できるようにする

  • 主な内容📚：

    • 17A：設計だけ（責務・依存矢印・公開API）🗺️
    • 17B：実装（usecase中心、I/Oは外側）🛠️
    • 17C：最小テスト（壊れやすい所だけでもOK）🧪

  • ハンズオン🛠️：題材例：ToDo＋締切通知✅⏰／備品貸出📦／簡易EC🛒（どれか1つ）

  • AIプロンプト🤖 1)「この設計、責務混在と依存増えすぎがない？危険点TOP5」 2)「最小テスト1本で守るべき仕様を提案して（壊れやすい所優先）」