Skills: リファクタリングスキル
最終更新:2026-08-31
リファクタリングは書き直しではない——振る舞いを変えずにコード構造を改善すること。Skills がリファクタリングを体系化します。
1. コードスメルの特定
(1) 一般的なコードスメル
| スメル | Grep パターン | リスク |
|---|---|---|
| 長い関数 | 行数 > 50 | 🟡 |
| 重複コード | 類似度 > 80% | 🟡 |
| 深いネスト | ネストレベル > 3 | 🟡 |
| マジックナンバー | ハードコーディングされた定数 | 🟢 |
| ゴッドクラス | メソッド数 > 20 | 🔴 |
| 循環依存 | 相互インポート | 🔴 |
(2) 自動検出
YAML
---
name: smell-detector
description: "コードスメルを検出"
tools:
- Grep
- Glob
- Read
---
MARKDOWN
## 検出フロー
1. Glob でファイルリストを取得
2. Grep でスメルパターンを検索
3. Read で詳細に確認
4. 深刻度順にレポートを出力
2. リファクタリング戦略
(1) スメル→リファクタリングの対応
| スメル | リファクタリング手法 | 複雑さ |
|---|---|---|
| 長い関数 | 関数の抽出 | 🟢 低 |
| 重複コード | メソッドの抽出/Template Method | 🟡 中 |
| 深いネスト | ガード句/Strategy パターン | 🟡 中 |
| マジックナンバー | 定数の抽出 | 🟢 低 |
| ゴッドクラス | 責務の分割 | 🔴 高 |
| 循環依存 | インターフェースの導入/Mediator | 🔴 高 |
(2) リファクタリングのリスク評価
TEXT
📖 参照専用
リファクタリングリスクマトリクス
影響小 影響大
変更小 🟢 安全 🟡 テストが必要
変更大 🟡 レビューが必要 🔴 段階的に実行
(3) リファクタリングの順序原則
MARKDOWN
## リファクタリングの順序
1. 低リスクを先に(定数の抽出→関数の抽出→クラスの分割)
2. 局所から全体へ(関数レベル→クラスレベル→モジュールレベル)
3. 各ステップで検証可能(小さなステップで進め、毎回テストを実行)
4. いつでも停止可能(どのステップの後でもコードが動作する状態に)
3. 安全なリファクタリングフロー
(1) リファクタリング前の準備
MARKDOWN
## 事前チェック
1. Bash:フルテストスイートを実行し、ベースラインの通過を確認
2. Bash:git commit で現在の状態をコミット(スナップショットポイント)
3. Read:リファクタリング対象の完全なコンテキストを理解
4. すべての呼び出し箇所を特定(誰がこのコードに依存しているか)
(2) リファクタリングの実行
TEXT
📖 参照専用
安全なリファクタリングループ
┌──────────────────┐
│ 1. 小さなステップで変更 │
│ 2. テストを実行 │
│ 3. テストは通った? │
│ ├─ はい → 続行 │
│ └─ いいえ → ロールバック │
└──────────────────┘
(3) リファクタリング後の検証
MARKDOWN
## 検証チェックリスト
- [ ] フルテストスイートが通過
- [ ] 機能的振る舞いが変更されていない
- [ ] コードがシンプル/クリーンになっている
- [ ] 新しい TODO/FIXME がない
- [ ] 循環依存がない
4. リファクタリング Skill の実践
▶ 例:安全な関数抽出
Alice は200行の長い関数をリファクタリングする必要があります:
YAML
---
name: safe-extract-function
description: "安全な関数の抽出"
tools:
- Read
- Edit
- Grep
- Bash
---
MARKDOWN
## 抽出フロー
1. Read で長い関数を分析し、独立したロジックブロックを特定
2. 抽出計画をリストアップ(どの行→新しい関数名)
3. ステップごとに実行:
a. Edit で元の関数の下に新しい関数を作成
b. Edit で元の関数が新しい関数を呼び出すように変更
c. Bash でテストを実行
4. すべての抽出完了後、フルテストスイートを実行
Bob は言います:「リファクタリングで最も怖いのは、コードを変えて機能を壊すこと——小さなステップで毎回検証する方が、全部変えてからテストするより1万倍安全だ。」
❓ よくある質問
Q リファクタリング中にテストが失敗したら?
A 直ちに最後に通過した状態までロールバックし、失敗原因を分析してください。よくある原因:見落とした呼び出し箇所、互換性のない関数シグネチャ、暗黙の依存関係。
Q リファクタリングはどこまでやるべきですか?
A チーム基準を満たすまでで十分——過度なリファクタリングは避けてください。目標はコードスメルの除去であり、完璧なアーキテクチャの追求ではありません。
Q リファクタリングと機能開発を同時に行えますか?
A お勧めしません。リファクタリングは振る舞いを変えず、機能開発は振る舞いを変えます。両者を混在させると問題の原因を特定できなくなります。
📖 まとめ
- コードスメルの特定:Grep/Glob パターンマッチングで自動検出
- リファクタリング戦略:スメル→手法の対応、リスク順に実行
- 安全なフロー:ベースラインテスト→小ステップ変更→段階的検証→ロールバック保証
- コア原則:各ステップが検証可能、ロールバック可能、停止可能
📝 練習問題
- 基礎問題(難易度⭐):少なくとも3つの一般的な問題を検出するコードスメル検出 Skill を作成してください。
- 応用問題(難易度⭐⭐):小ステップ抽出+段階的検証を実装する安全な関数抽出 Skill を作成してください。
- チャレンジ問題(難易度⭐⭐⭐):スメルを自動特定し、手法を選択し、安全な順序で実行し、変更前後の比較レポートを出力するスマートリファクタリング Skill を作成してください。