How to コードベースをリファクタリングする with Eigent

仕組み

1. 編集前に、Eigent に対象領域のマッピングを依頼します。ノイズの多いモジュール、重複ロジック、未使用コード、古いパターンを洗い出します。
2. 一度に 1 つの整理テーマだけを選びます。不要コードの削除、制御フローの簡素化、古いパターンの最新化、大きなファイルの分割のいずれかに絞ります。
3. Eigent がファイルを修正する前に、現在の動作、構造上の改善点、そして動作が安定していることを示す最小の検証方法を明示させます。
4. すべてをまとめて 1 つの差分にするのではなく、各パスごとに最小限の有用な検証を実行して確認します。
5. スタック変更、依存関係の移行、アーキテクチャ変更は、整理を完了するために必要な場合を除き、別タスクとして扱います。

試す追加プロンプト

• この領域で、不要コードや未使用の export が最も多いファイルはどれですか？
• 同じロジックが重複している箇所をすべて特定し、統合の単一ポイントを提案してください。
• このモジュールで、リポジトリの現在の規約と衝突しているレガシーパターンは何ですか？
• 公開 API を変えずに、この肥大化したファイルを、より小さく責任範囲が明確な複数ファイルに分割してください。

使い方

まず Eigent に散らかった領域のマッピングを依頼します。すると、コードに触れる前に最も価値の高い整理候補を特定します。1 テーマずつ進め、各差分を確認してから次へ進みます。各パスの後には、テストスイートまたは CI を検証項目として使用します。Eigent がスタック移行や依存関係変更を提案した場合は、別タスクとして扱い、現在のリファクタリングは構造改善のみに集中させてください。

期待される出力

優先順位付きの整理計画、少しずつ絞った小さな差分の連続（1 パスにつき 1 つ）、および各パスの検証サマリー。そこには、何を変更したかと、どの確認によって動作が安定していると判断できるかを含めます。

制限事項

• 対象領域に既存のテストスイート、または検証可能な明確な動作契約がある場合に最も効果を発揮します。
• 大規模なモノレポでは、1 度に 1 つのサービスまたはモジュールに絞ると効果的です。
• アーキテクチャ変更、ランタイムのアップグレード、フレームワーク移行は別タスクにしてください。リファクタリングと混ぜると差分がレビュー不能になります。