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

第26章：総合演習1 まずは「作戦」を立てよう📝🔍✨

（いきなりコードを触らず、壊さないための計画を作る章だよ〜！😊💖）

この章のゴール🎯✨​

この章が終わると、あなたはこうなります👇💪

  • ぐちゃぐちゃなコードを見て「どこが痛いか」をSOLIDの言葉で説明できる🗣️✨
  • いきなり直さず、安全に直す順番（リファクタ計画）を作れる🧭🧹
  • AI（Copilot/Codex系）に「調査の手伝い」をさせつつ、最後は自分の判断で決められる🤖🧠✨

まず大事な事実メモ📌（2026の現実）​

  • .NET 10 は 2025年11月11日にリリースされた LTSで、サポートは 2028年11月頃までの予定だよ✅ (Microsoft for Developers)
  • Visual Studio 2026 は .NET 10 / C# 14 対応が公式に書かれてるよ🧰✨ (Microsoft Learn)
  • C# 14 は .NET 10 SDK と Visual Studio 2026で試せる（＝標準スタックとして成立してる）よ🧡 (Microsoft Learn)
  • GitHub Copilot は Visual Studio 側も要件があって、少なくとも VS 2022 17.8+ が対象（VS 2026 でも当然流れ的にOK）って扱いだよ🤖✨ (GitHub Docs)

今日の題材（ミニEC）🛒📦​

例として「注文→支払い→発送」あたりが全部混ざってる OrderService地獄を想像してね😇💥 ※この章では 直さない。まず「作戦」を立てる！

1) 作戦を立てる前の“安全装置”🔒🧪

「計画だけ」でも、最低限これやると事故率が激減するよ🙏✨

✅ 1-1. ブランチを切る🌿​

  • refactor/ch26-plan みたいな名前でOK👍✨
  • 小さくコミットしやすくなるよ🎁

✅ 1-2. 変更前の動作を“メモ”する📝​

テストがまだ薄いなら、まず 観察ログを残すのが強いよ💡

  • 代表ケース：

    • 注文作成（正常）
    • 在庫なし（失敗）
    • 支払い失敗（失敗）
    • 発送登録（正常）

  • 「入力→出力」「DBに何が入るか」「外部APIに何を投げるか」だけでOK👌✨

✅ 1-3. 最低限の“スモークテスト”だけ作る🔥​

この章でガチテスト設計はやらないけど、壊してない確認は超大事！🧪

  • まずは「代表ケースが通る」程度でOK
  • 本格テストは第28章で整えるイメージで大丈夫🙆‍♀️✨

2) コードを“地図化”する🗺️👀

Refactoring Roadmap: Legacy Forest to SOLID City.

作戦は、地図がないと立てられないよ〜！

✅ 2-1. 入口（ユースケース）を見つける🚪​

例：

  • Controller / Handler / UI から呼ばれる「注文作成」
  • バッチから呼ばれる「発送同期」

「どこが入口で、どこまでが1処理か」を先に決めるのがコツ😊✨

✅ 2-2. 依存関係をざっくり列挙する🧲​

OrderServiceが触ってるものを箇条書きしてね👇

  • DB（OrderRepository / DbContext）🗄️
  • 決済（PaymentGateway）💳
  • 配送（ShippingApi）🚚
  • メール（EmailSender）📧
  • ログ（Logger）📜
  • 設定（Config）⚙️

ここで「多っ！」ってなったら、だいたい SRP違反の匂いだよ😂

3) SOLID違反を“ラベル貼り”する🏷️✨

ここが第26章のメイン💖 「違反を見つける → 直す順番を決める」が目的だよ！

✅ 3-1. SRP違反（変更理由が複数）📌​

チェック質問👇

  • 「このクラス、何の理由で変更される？」
  • 「仕様変更が来たとき、関係ないのに巻き込まれる？」

例（OrderServiceでありがち）😇

  • 割引仕様が変わる→OrderService修正
  • 決済会社が変わる→OrderService修正
  • 発送APIが変わる→OrderService修正
  • DBの都合が変わる→OrderService修正

→ 変更理由が多すぎ＝SRP的にアウト寄り😵‍💫

✅ 3-2. OCP違反（if/switchが増殖）🚪💥​

  • if (paymentMethod == ...)
  • switch (shippingType) ...

「追加のたびに既存修正」になってたら危険⚠️ 将来の追加点が見えるところをマークしてね🖍️✨

✅ 3-3. LSP違反（置換できない継承）🧱➡️💥​

  • 子クラスで急に例外投げる
  • 親の約束（事前条件/事後条件）を変える

この章では「疑い箇所に付箋」くらいでOK👌

✅ 3-4. ISP違反（太いインターフェース）✂️📄​

  • IOrderService に “更新/参照/配送/決済/通知” ぜんぶ入ってる
  • 使わないメソッド実装が発生してる

→ 「利用者ごとに必要な形」が違うのに一枚岩だと辛い😵‍💫

✅ 3-5. DIP違反（上位が下位詳細に直依存）🧲🔻​

※第26章では“発見”まででOK！

  • new SqlConnection(...) を業務ロジック内でやってる
  • new HttpClient() をベタ書きしてる
  • PaymentGatewayXyz を直接呼んでる

→ 「差し替え不能」な匂いがする場所をマーク🖍️✨

4) “直す順番”を決めるコツ🧭✨

ここ、センスじゃなくてルール化できるよ😊

✅ 4-1. 優先順位ルール（超おすすめ）🥇​

基本はこの順が安全👇

  1. テスト/観察で守る（最小でOK）🧪
  2. I/O境界を薄くする（DB/HTTP/メールを“端に寄せる”）🚧
  3. **巨大クラスを分割（SRP）**🧹
  4. **分岐を戦略へ（OCP）**🎭
  5. 必要ならIF分割（ISP）✂️
  6. 最後に **依存差し替え（DIP/DI）**🔌（これは第28章が主戦場！）

理由：

  • いきなりDIから入ると「構造が変わりすぎ」て壊れやすい😭
  • 先に“塊”を整理してから、最後に配線（DI）すると気持ちいい✨

✅ 4-2. 1回の変更は“小さく”📦​

  • 1コミット＝1意図
  • 1PR＝1テーマ
  • 「SRP分割だけ」「OCP化だけ」みたいに切ると勝ち🏆

5) リファクタリング計画書テンプレ📝✨

この章の成果物はコレ！ チーム開発でも、そのまま設計メモとして通用するやつ😊💕

# リファクタリング計画書（第26章）

## 0. 現状の入口（ユースケース）
- UC1: 注文作成（画面）
- UC2: 注文キャンセル（画面）
- UC3: 発送登録（バッチ）

## 1. 現状の問題（観察ベース）
- 例：注文作成が失敗するときの条件が分かりづらい
- 例：支払い方法追加で OrderService が毎回編集される
- 例：外部APIの例外で処理が中途半端に終わる

## 2. SOLID違反メモ（疑いでOK）
### SRP
- OrderService が「注文生成/割引/決済/発送/通知/永続化」まで担当

### OCP
- paymentMethod の if/switch が増殖ポイント

### LSP
- 〇〇Payment が条件で例外を投げる（置換怪しい）

### ISP
- IOrderService が太すぎ、参照だけの画面でも更新系が見える

### DIP
- OrderService が PaymentGatewayXyz / ShippingApiClient を直呼び

## 3. 直す順番（小さく刻む）
Step1: 代表ケースのスモークテスト追加（壊れてない保証）
Step2: OrderService から「通知」「配送」「決済」を一旦 “薄いラッパー” に寄せる
Step3: SRPで分割（Pureなドメイン処理を中心に）
Step4: OCP化（支払い方法をStrategyへ）
Step5: ISP化（参照用IFと更新用IFを分離）
Step6: DIP/DI（Composition Root に寄せる：第28章）

## 4. 完了条件（Definition of Done）
- 代表ケースが全部通る
- OrderService が責務を説明できる単位に分割されている
- 支払い方法追加が「クラス追加」で済む
- 外部I/Oを差し替え可能にできる見通しが立っている

6) AI（Copilot/Codex）を“作戦参謀”にする🤖🎖️

AIは「コード改造マン」より、まず「調査補助」にすると超強いよ✨

✅ 6-1. まず投げると強いプロンプト集💬✨​

① SOLID違反の棚卸し​

このクラス（OrderService）の責務を「変更理由」という観点で列挙して。
その上で SRP/OCP/LSP/ISP/DIP の観点で違反（または疑い）を分類して。
最後に「安全なリファクタ順」を提案して。

② 分岐の未来予測（OCP）​

この switch/if は将来どんな種類が増えそう？
増える前提で Strategy に分けるなら、Strategy の種類と責務名を提案して。

③ “最小の安全網”提案（テスト）​

この処理を壊さずにリファクタしたい。
最小限のスモークテストケース（3〜6個）を提案して。入力と期待結果も書いて。

✅ 6-2. AIの答えをそのまま信じないコツ🙏​

  • それっぽい設計名を盛りがち😇（過剰抽象化）
  • “今必要な追加”に寄せて、未来は作りすぎない⚖️
  • 採用するときは「なぜそれが必要？」を自分の言葉で言えるかチェック🧠✨

7) ありがちな失敗と回避😵‍💫➡️😊

❌ 失敗1：いきなりDIコンテナ整理を始める​

→ 変更範囲が爆発して、バグる💥 ✅ 回避：まず「責務の塊」を整える（第27章の領域）✨

❌ 失敗2：テスト0で大改造​

→ “壊れても気づけない”😇 ✅ 回避：代表ケースだけでも作る🧪✨

❌ 失敗3：抽象化しすぎ（未来を作りすぎ）​

→ クラスが増えて逆につらい😂 ✅ 回避：「次に増えるもの」だけを拡張点にする🎯

8) この章のミニ課題🎒✨

あなたのプロジェクト（またはサンプル）で👇を作ってね😊

  • ✅ 入口ユースケースを3つ書く🚪
  • ✅ 依存（DB/HTTP/メール等）を列挙する🧲
  • ✅ SOLID違反（疑いでOK）をラベル貼り🏷️
  • ✅ 「直す順番」を6ステップで書く🧭
  • ✅ 完了条件（DoD）を4つ書く✅

まとめ🎀✨​

第26章で一番えらいのはコレ！👇😊

  • コードを触る前に“作戦”を作ったこと📝✨
  • SOLIDを“暗記”じゃなく“診断ツール”として使ったこと🩺🌈
  • AIを“調査員”として使って、自分で最終判断したこと🤖🧠💖

次の第27章では、この計画書をもとに クラス構造を綺麗に整えるよ〜！🧱✨