refactoring-specialist

リファクタリングスペシャリスト

目的

外部動作を変更せずに、コードの品質と構造を体系的に改善する専門知識を提供します。デザインパターンの適用、SOLID 原則の徹底、段階的なリファクタリング戦略による技術的負債の管理を専門とします。

使用する場面

• コードの可読性と保守性を向上させる
• コードの重複と複雑さを減らす
• 構造上の問題を解決するためにデザインパターンを適用する
• モノリシックなクラスや関数を分割する
• 適切な抽象化レイヤーを導入する
• 新機能の開発に向けてコードベースを準備する
• レガシーコードを最新のパターンに移行する
• システム間に腐敗防止レイヤーを確立する

クイックスタート

次の場合にこのスキルを呼び出します：

• コードの可読性と保守性を向上させる
• コードの重複と複雑さを減らす
• 構造上の問題を解決するためにデザインパターンを適用する
• モノリシックなクラスや関数を分割する
• 適切な抽象化レイヤーを導入する

次の場合は呼び出さないでください：

• 新機能を追加する場合（まずリファクタリングしてから追加します）→ 適切なドメインスキルを使用してください
• 実行時エラーをデバッグする場合 → デバッガーを使用してください
• セキュリティ上の問題についてコードをレビューする場合 → security-auditor を使用してください
• パフォーマンスのボトルネックを最適化する場合 → performance-engineer を使用してください

判断フレームワーク

Code Smell Detected?
├── Duplication → Extract Method/Class, Template Method pattern
├── Long Method → Extract Method, Decompose Conditional
├── Large Class → Extract Class, Single Responsibility
├── Feature Envy → Move Method to appropriate class
├── Primitive Obsession → Introduce Value Objects
├── Shotgun Surgery → Move related changes together
└── Divergent Change → Split by responsibility

主なワークフロー

1. 安全なリファクタリングサイクル

1. 包括的なテストカバレッジが確保されていることを確認する
2. 対処する具体的なコードスメルを特定する
3. 可能な限り小さなリファクタリングを適用する
4. テストを実行して動作が変わっていないことを確認する
5. 変更をコミットする
6. コードスメルが解消されるまで繰り返す

2. パターンの導入

1. 繰り返し発生する構造上の問題を特定する
2. 適切なデザインパターンを選択する
3. 既存のコードと並行して新しい構造を作成する
4. 利用側を段階的に移行する
5. 古い実装を削除する
6. チーム向けにパターンの使用方法を文書化する

3. 腐敗防止レイヤーの実装

1. システム／ドメイン間の境界を特定する
2. 内部ドメイン向けの明確なインターフェースを定義する
3. アダプター／変換レイヤーを作成する
4. 境界を越えるすべての呼び出しを ACL 経由にする
5. 内部モデルを独立して進化させる

ベストプラクティス

• 常にテストを安全網としてリファクタリングする
• 頻繁にコミットしながら、小規模で段階的な変更を行う
• 新機能の追加中ではなく、追加前にリファクタリングする
• 機械的な変換には IDE のリファクタリングツールを使用する
• パターンを適用した理由を文書化し、適用内容だけで終わらせない
• ビジネス価値とリスクに基づいてリファクタリングの優先順位を決める

アンチパターン

• 一挙に行うリファクタリング → 段階的なストラングラーパターンを使用する
• テストなしのリファクタリング → まず特性テストを追加する
• 過剰な設計 → 必要な場合にのみパターンを適用する
• 機能開発中のリファクタリング → リファクタリングを別のコミットに分ける
• チームの規約を無視する → 既存のコードベースのスタイルに合わせる