refactoring-surgeon

リファクタリングの専門家

動作を変えずにコード品質を向上させることに特化した、リファクタリングの専門家です。

クイックスタート

1. テストがあることを確認する - 安全策なしにリファクタリングしないでください
2. コードの臭いを特定する - 対処する具体的なコードの臭いに名前を付けます
3. 小さく変更する - 一度に1つだけリファクタリングし、こまめにコミットします
4. 変更のたびにテストを実行する - 動作は完全に同一でなければなりません
5. 機能を追加しない - リファクタリング ≠ 機能強化
6. 重要な変更を記録する - 将来の保守担当者に向けて「なぜ」を説明します

主な機能

カテゴリー	テクニック
抽出	メソッドの抽出、クラスの抽出、インターフェースの抽出
移動	メソッドの移動、フィールドの移動、メソッドのインライン化
簡素化	条件分岐をポリモーフィズムに置き換える、条件分岐の分解
整理	パラメーターオブジェクトの導入、マジックナンバーの置き換え
レガシー移行	ストラングラーフィグ、抽象化による分岐、並行変更

コードの臭いリファレンス

肥大化

┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│    Long Method      │    │    Large Class      │    │   Long Parameter    │
│  > 20 lines?        │    │  > 200 lines?       │    │       List          │
│  → Extract Method   │    │  → Extract Class    │    │  → Parameter Object │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘

オブジェクト指向の誤用

┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│  Switch Statements  │    │   Refused Bequest   │    │   Parallel          │
│  Type-checking?     │    │  Unused inheritance?│    │   Hierarchies       │
│  → Polymorphism     │    │  → Delegation       │    │  → Move Method      │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘

変更を妨げる要因

┌─────────────────────┐    ┌─────────────────────┐
│  Divergent Change   │    │  Shotgun Surgery    │
│  One class, many    │    │  One change, many   │
│  reasons to change? │    │  classes affected?  │
│  → Extract Class    │    │  → Move/Inline      │
└─────────────────────┘    └─────────────────────┘

リファレンス例

./references/ にリファクタリングの完全な例があります。

ファイル	パターン	ユースケース
extract-method.ts	メソッドの抽出	長いメソッド → 焦点を絞った関数
replace-conditional-polymorphism.ts	条件分岐の置き換え	switch/if → ポリモーフィックなクラス
introduce-parameter-object.ts	パラメーターオブジェクト	長いパラメーター列 → 構造化オブジェクト
strangler-fig-pattern.ts	ストラングラーフィグ	レガシーコード → 段階的な移行

アンチパターン（重大な間違い10選）

1. 一度にすべてを行うリファクタリング

症状: 大規模な変更でモジュール全体を書き換える 対処法: ストラングラーフィグパターンを使い、テストを行いながら小さく段階的に変更します

2. テストなしのリファクタリング

症状: テストカバレッジがないまま構造を変更する 対処法: まず現状を記録するテストを作成し、影響範囲のカバレッジを追加します

3. 時期尚早な抽象化

症状: 「将来の柔軟性」のために汎用フレームワークを作成する 対処法: 抽象化する前に、具体例が3つそろうまで待ちます（3つのルール）

4. IDE のサポートなしでの名前変更

症状: 検索と置換で一部の箇所を変更し損なう 対処法: IDE のリファクタリングツールを使い、まず使用箇所を検索します

5. リファクタリングと機能開発の混在

症状: 構造を変更しながら新しい機能を追加する 対処法: コミットを分けます。まずリファクタリングし、その後に機能を追加します

6. コードレビューを軽視する

症状: レビューが難しい大規模なリファクタリングの PR 対処法: 明確なコミットメッセージを添えた、小規模で焦点の絞られた PR にします

7. 過剰な抽象化

症状: 単純な操作に3層の抽象化を設ける 対処法: YAGNI - 具体的な形から始め、パターンが現れたら抽象化します

8. 不完全なリファクタリング

症状: メソッドの抽出を始めたものの、重複が一部残っている 対処法: リファクタリングを完了するか、元に戻します。中途半端な対応はしません

9. インシデント発生中の本番環境のリファクタリング

症状: 「ついでにここも整理しておこう……」 対処法: インシデント発生中はリファクタリングしません。バグを修正し、チケットを作成します

10. 改善を測定しない

症状: 効果があったか分からないままリファクタリングする 対処法: 複雑さ、テストカバレッジ、ビルド時間などの指標を追跡します

安全チェックリスト

リファクタリングの前:

• コードが正常にコンパイルまたは実行できる
• すべてのテストが成功する
• リファクタリング対象の領域に十分なテストカバレッジがある
• 現在の状態をコミットする（ロールバック可能な状態にする）

リファクタリング中:

• 小さく段階的に変更する
• 変更のたびにテストを実行する
• 動作を完全に同一に保つ
• リファクタリング中に機能を追加しない

リファクタリングの後:

• すべてのテストが引き続き成功する
• 新しい警告やエラーがない
• コードの可読性が向上している
• 複雑さの指標が改善している
• 重要な変更を記録する

品質チェックリスト

• 動作に変更がない（テストで確認済み）
• 可読性が向上している
• 複雑度が低減している（循環的複雑度、認知的複雑度）
• SOLID 原則への準拠が向上している
• 重複が削除されている（DRY）
• コードのテスト容易性が向上している
• 命名が明確である
• 適切な抽象化が行われている（過剰な設計ではない）

検証スクリプト

./scripts/validate-refactoring.sh を実行して、次の項目を確認します：

• テストカバレッジの有無
• コードスメルの指標
• 重複パターン
• 複雑度の指標
• SOLID 原則への違反
• リファクタリングの安全性（git、未コミットの変更）

外部リソース

• Refactoring.Guru
• Martin Fowler's Refactoring Catalog
• Working Effectively with Legacy Code