既存コードのリファクタリング
既存コードの改善はAIの得意分野です。コードの分析、問題点の特定、改善案の提示、そして実装まで、AIと協力して効率的にリファクタリングを進めましょう。
AIを使ったリファクタリングの流れ
1
コードを分析させる
AIにコードを読ませ、問題点を洗い出す
2
改善案を提案させる
複数のアプローチを比較検討
3
テストを先に書く
リファクタリング前に動作を保証するテストを作成
4
段階的にリファクタリング
小さな変更を積み重ね、都度テスト
5
レビューと確認
AIに再度レビューさせ、改善を確認
Step 1: コードを分析させる
分析を依頼するプロンプト
以下のコードをレビューして、問題点と改善案を教えてください。 【観点】 1. 可読性（変数名、関数の長さ、コメント） 2. 保守性（責任の分離、重複コード） 3. パフォーマンス（N+1問題、不要な処理） 4. セキュリティ（入力検証、機密情報の扱い） 5. テスト容易性（依存関係、モック可能性） 【コード】 ```python # ここに分析したいコードを貼り付け ```
分析結果の例
問題1: 関数が長すぎる
process_order() が200行を超えています。責任を分割すべきです。
問題2: N+1クエリ
ループ内でDBクエリを実行しています。joinで一括取得すべきです。
問題3: マジックナンバー
`if status == 3` のような意味不明な数値。定数化が必要です。
Step 2: 改善案を提案させる
改善案を依頼するプロンプト
指摘された問題について、具体的な改善案を示してください。 【問題1: 関数が長すぎる】 process_order() をどのように分割すべきですか？ 各関数の責任と、呼び出し関係を示してください。 【問題2: N+1クエリ】 現在のコードと、改善後のコードを両方示してください。 パフォーマンスの違いも説明してください。
Step 3: テストを先に書く
重要：リファクタリング前に、現在の動作を保証するテストを書きましょう。これにより、リファクタリング後も同じ動作をすることを確認できます。
テスト作成を依頼
リファクタリング前に、現在の process_order() の動作を保証するテストを書いてください。 【テストすべきケース】 1. 正常系：通常の注文処理 2. 在庫不足の場合 3. 決済失敗の場合 4. 境界値：数量が0や負の場合 現在の実装を「正」として、テストを作成してください。
Step 4: 段階的にリファクタリング
リファクタリングの鉄則
○ やるべきこと
- ・小さな変更を1つずつ
- ・変更ごとにテスト実行
- ・変更ごとにコミット
- ・動作を変えずに構造だけ変える
✗ 避けるべきこと
- ・一度に大量の変更
- ・機能追加とリファクタリングの同時実行
- ・テストなしでの変更
- ・「ついでに」の修正
段階的なリファクタリング指示例
process_order() のリファクタリングを段階的に行います。 まず最初のステップとして、バリデーション部分だけを validate_order() として抽出してください。 【制約】 - 動作は変えない - 他の部分は触らない - このステップだけでテストが通ることを確認 完了したら次のステップに進みます。
Step 4-1
バリデーション部分を抽出 → テスト → コミット
Step 4-2
在庫チェック部分を抽出 → テスト → コミット
Step 4-3
決済処理部分を抽出 → テスト → コミット
Step 4-4
N+1問題を解決 → テスト → コミット
AIに依頼しやすいリファクタリングパターン
関数の抽出
「この部分を独立した関数に抽出して」
変数名の改善
「より意味のある変数名に変更して」
重複コードの除去
「重複している部分を共通化して」
条件分岐の簡素化
「ネストを減らして可読性を上げて」
マジックナンバーの定数化
「数値リテラルを意味のある定数に」
型の追加
「型アノテーションを追加して」
まとめ
- ✓ まず分析 - AIに問題点を洗い出させる
- ✓ テストを先に - 動作を保証してからリファクタリング
- ✓ 小さく進める - 1つの変更→テスト→コミットを繰り返す
- ✓ 動作を変えない - 構造だけを改善する
- ✓ AIに段階的に依頼 - 一度に全部ではなくステップごと