refactor-process

リファクタリングプロセス

この手順を実行する前に、実行契約を適用してください。

クイックリファレンス

項目	ルール
前提条件	編集を始める前に、特性テストが存在し、すべて成功している必要があります
ステップの規模	一度に行うのは、1つのアトミックな変換のみです（変数名の変更、メソッドの抽出など）
検証	各ステップの後に、必ずテストを実行してください
動作の変更禁止	リファクタリング中に新機能、バグ修正、戻り値の変更を行わないでください
ロールバック	テストが失敗した場合は、すぐに元に戻してください。壊れた状態でデバッグしてはいけません

手順

ステップ 1：ベースラインを確立する

• クラスまたはモジュールの既存のテストを実行します。
• カバレッジが不足している、または不十分な場合は、特性テスト（エッジケースやエラーを含む現在の動作を記録するテスト）を作成します。
• 続行する前に、すべてのテストが成功することを確認します。

ステップ 2：ステップを計画する

• 目標を特定します（例：複雑なメソッドを独立したクラスに抽出する、条件分岐を簡潔にする）。
• 目標を一連のアトミックなリファクタリング操作（名前変更、抽出、インライン化、移動、条件分岐の置き換えなど）に分割します。

ステップ 3：実行と検証を繰り返す

計画した各ステップで、次を行います。

1. 単一のアトミックなコード変更を行います。
2. テストを実行します。
3. すべて成功した場合は、そのステップを保存またはコミットして、次に進みます。
4. 失敗した場合は、変更を破棄し（例：git checkoutまたは取り消し）、根本原因を分析して、より小さなステップを試します。

---

チェックポイントのパターン

ユーザーと確認しながら進めます。

1. ベースラインのチェックポイント： 編集を始める前に、特性テストと現在の実装を提示します。
2. リファクタリングの提案： 予定している変換手順を説明します。
3. 完了チェックポイント： 最終的なリファクタリング済みコードと、テストスイートの検証レポートを提示します。

---

リファクタリングループの例（メソッドの抽出）

ベースライン（成功）：

class ReportGenerator
  def generate(data)
    # Formats raw data to report
    formatted = data.map { |row| "#{row[:id]}: #{row[:name].strip.capitalize}" }
    
    # Renders report
    "=== Report ===\n" + formatted.join("\n") + "\n=============="
  end
end

ステップ 1：フォーマッターのロジックを抽出する（アトミックな編集）：

class ReportGenerator
  def generate(data)
    formatted = format_rows(data)
    "=== Report ===\n" + formatted.join("\n") + "\n=============="
  end

  private

  def format_rows(data)
    data.map { |row| "#{row[:id]}: #{row[:name].strip.capitalize}" }
  end
end

アクション： すぐにテストを実行します。すべて成功することを確認します。

---

アンチパターン

• 動作の拡大： リファクタリングと動作の変更（バグ修正、最適化）は完全に別のコミットに分けます。
• 「大飛躍」のリファクタリング： 一度に複数の重要な変更を行うと、失敗の原因を特定しにくくなります。常に可能な限り小さなアトミックなステップで進めてください。

連携

コンテキスト	次のスキル
ベースラインのカバレッジ確立	test-planning-process → tdd-process
新たに抽出した API のドキュメント作成	write-yard-docs
リファクタリング後のレビュー	review-process