refactor-code

コードのリファクタリング

意図した動作を変えずに構造を変更するタスクで、このスキルを使用します。

基本原則： 大規模な書き換えより、小さく元に戻せる手順を優先します。設計の改善と動作の変更は分けて行います。

クイックリファレンス

手順	アクション	検証
1	安定した動作を定義する	変更してはならない内容を明記する
2	特性テストを追加する	現在のコードでテストが通る
3	最小限で安全な範囲を選ぶ	一度に1つの境界だけを扱う
4	名前を変更、移動、または抽出する	テストが引き続き通る
5	互換性用のシムを削除する	テストが引き続き通り、新しい経路が実証されている

HARD-GATE

NO REFACTORING WITHOUT CHARACTERIZATION TESTS FIRST.
NEVER mix behavior changes with structural refactors in the same step —
  if behavior changes are also needed, complete the structural refactor first,
  then apply behavior changes in a separate step with its own test.
ONE boundary per refactoring step — never extract two abstractions in the same step.
If a public interface changes, document the compatibility shim and its removal condition.
NEVER fabricate test output — label only actual run output as Observed output.

基本プロセス

1. 安定した動作を定義する

リファクタリング対象のロジックに対する入力と出力を正確に特定します。呼び出し元の移行が完了するまでは、公開インターフェースを安定させてください。移行期間中は、アダプター、ファサード、またはラッパーを優先します。

出力には以下を含めてください：

• 安定した動作の説明： 変更してはならない内容（入出力、公開インターフェース）を明示します。
• シムの判断： 移行用アダプター／ファサード／ラッパーがあれば、その名前と削除条件を示します。不要な場合はその理由を述べます。

2. 特性テストを追加する

本番ファイルに手を加える前に、これを書いてください。 このテストが作成され、現在の（リファクタリング前の）コードで合格するまでは、リファクタリングの手順を開始しないでください。特性仕様に失敗した場合は、続行せずに停止し、テストまたは動作の不一致を修正してください。

# spec/requests/orders_spec.rb  (or service/model spec — mirror the file being refactored)
# frozen_string_literal: true

RSpec.describe "Orders#create current behavior", type: :request do
  describe "POST /orders" do
    let(:valid_params) { { order: { product_id: 1, quantity: 2 } } }

    it "creates order and enqueues warehouse notification" do
      expect { post orders_path, params: valid_params }
        .to change(Order, :count).by(1)
      expect(NotifyWarehouseJob).to have_been_enqueued
    end
  end
end

実行します：bundle exec rspec spec/requests/orders_spec.rb — 現在のコードで合格する必要があります。

3. 最小限で安全な範囲を選ぶ

最初に行うとよい変更には、わかりにくいメソッド名の変更、重複したロジックを共有オブジェクトの背後に切り分けること、呼び出し箇所を移動する前に外部連携をラップすることなどがあります。古いコード経路を削除する前に、対象を絞った接点を追加してください。一度に扱う境界は1つだけにします。まず特性テストを行い、各手順の後に検証します。

4. 抽出／リファクタリングを実行する（一度に1ステップ）

ロジックを抽出、移動、または改名します。リファクタリングによって明瞭さよりも間接性が増す場合は、作業を止めて簡素化してください。

最小限のインライン例（コントローラーのオーケストレーションの抽出）

変更前：

def create
  order = OrderCreator.new(params).call
  NotifyWarehouseJob.perform_later(order.id)
  redirect_to order_path(order)
end

変更後：

def create
  order = Orders::CreateOrder.call(params: params)
  redirect_to order_path(order)
end

参考資料（段階的な開示）

各ファイルは、記載内容が必要な場合にのみ読み込んでください。

• assets/complete_example.md — 計画、安定した動作、特性テスト、手順ごとの検証実行、最終的なテストスイート検証コマンドの出力を示す、高評価の answer.md の完全なステップバイステップ例。
• EXAMPLES.md — サービスの抽出や、小さな単位での改名に関するその他の例。

5. 検証プロトコル

リファクタリングの各手順の後に検証を実行します。

1. テストスイート全体を実行します。
2. 出力を読み、終了コードと失敗数を確認します。
3. テストが失敗した場合：停止し、その手順を元に戻して原因を調査します。
4. テストが合格した場合：次の手順に進みます。
5. 最後のテスト実行の証拠がある場合に限り、完了を宣言します。出力の最終行（例：「5 examples, 0 failures」）を報告します。

テスト実行の出力は最後だけでなく、各手順で報告してください。異なる段階でのObserved outputエントリを、少なくとも2つ記載する必要があります。

証拠のラベル付け規則： 実際に実行した出力に限り、Observed outputとラベル付けしてください。実際に観測した出力の代わりに、「Expected output」「Required output」「Planned output」や「Must produce 0 failures」などのラベルを使ってはいけません。テストを実行していない場合、報告できる観測出力はありません。