refactoringlisted

# リファクタリング支援スキル ## 1. 大原則 1. **テストを先に整える**。テスト無しのリファクタは禁止。 2. **小さく · こまめに** 変更する（1 PR 1 リファクタ単位）。 3. **挙動を変えない**。仕様変更が混入したら CR 起票。 4. **計測してから判断する**（性能改善は推測でなく実測で）。 5. **後方互換性を保つ**。外部 API · 公開関数のシグネチャ変更には CR 必須。 --- ## 2. 手順 ### Step 1：現状把握 - 対象モジュールの **責務** · **依存関係** · **使われ方** を把握。 - 既存テストのカバレッジを確認（不足ならテスト追加が先）。 - 過去の改修履歴（git log）から **触りにくい理由** を察知。 ### Step 2：問題の特定 代表的な「コードの臭い」（`code smell`）を観点別にチェック： | 観点 | 臭い | リファクタ手段 | | --- | --- | --- | | 構造 | God Class（巨大クラス） | クラス分割 · ドメイン抽出 | | 構造 | Long Method（巨大メソッド） | Extract Method | | 重複 | Duplicate Code | Extract Function · 共通化 | | 結合度 | Feature Envy（他クラスのフィールド多用） | Move Method | | 凝集度 | Data Class（データだけ��クラス） | 振る舞いを移動 | | 抽象化 | Magic Number / String | 定数化 | | 抽象化 | Switch on Type | ポリモーフィズム化 | | テスト | Hidden Dependency | DI · インターフェース化 | | 可読性 | 不明瞭な命名 | 改名 | | 可読性 | 深いネスト | Guard Clause / Early Return | | 性能 | N+1 / 大量メモリ | クエリ改善 · ストリーミング | ### Step 3：段階的計画 リファクタは **1 PR 1 トピック**。複数の臭いを 1 PR に詰めない。 例： ``` Phase 1: テスト追加（カバレッジ 50% → 85%） Phase 2: God Class を 3 クラスに分割（PR #1） Phase 3: Magic Number を Enum に置換（PR #2） Phase 4: 深いネストを Guard Clause で平坦化（PR #3） Phase 5: 性能改善（実測 → クエリ修正）（PR #4） ``` ### Step 4：実装 各 PR で： 1. テストを先に green に保つ。 2. **小さく commit**（1 commit = 1 機械的変換）。 3. 名前変更 · メソッド抽出 等の **機械的リファクタ** は IDE 機能を活用。 4. 都度テスト実行。 ### Step 5：検証 - ✅ 既存テストが全件通る。 - ✅ カバレッジが下がっていない。 - ✅ 静的解析エラーが増えていない。 - ✅ 性能リファクタの場合、ベンチマークで改善を確認。 - ✅ 仕様変更が混入していない（PR Description に「挙動変更なし」と明記）。 --- ## 3. リファクタ提案フォーマット ```mar