Claude Codeでリファクタリングする：振る舞いを保つ範囲を決める

外部契約を列挙する

関数の戻り値だけでなく、エラーの種類、保存形式、URL、操作順序、実行回数も振る舞いの一部です。重複した処理を共通化すると、呼び出される時点や状態の共有範囲が変わることがあります。

過去のデータを読む必要がある場合は、その形式も維持条件にします。新しい形へ統一するために古いデータを読めなくするなら、単なる整理ではなく互換性の変更として扱う必要があります。

抽象化の利益を具体的にする

共通化する理由が「同じ見た目だから」だけなら、将来の変更方向が異なる可能性があります。どの誤りを減らし、どの変更を一箇所で行えるようにするのかを説明します。

小さな修正のために新しい汎用フレームワークまで作ると、確認範囲が広がります。既存の実装を使い、必要な箇所だけを整理する選択肢も比較します。

差分と振る舞いを両方確認する

変更量が小さくても影響が大きいことがあり、行数だけでは判断できません。境界入力、失敗時、複数回の呼び出しで契約が保たれるかを確認します。機能の変更が必要になった場合は、その理由と範囲を整理し、整理の作業へ黙って混ぜないようにします。

比較の単位を関数から利用場面へ広げる

関数の入出力が同じでも、共有する状態や呼び出す順序が変わると、画面や保存処理の振る舞いが変わることがあります。通常の一回の呼び出しだけでなく、連続した操作、途中の失敗、同時の要求を含めて考えます。共通化した部品を使う全ての場所を列挙し、そのうち今回の変更で影響する用途を確認することが重要です。

整理の前後で、利用者が頼っている契約を短く書き出して比較します。戻り値だけでなく、既存データを読めること、エラー後に再開できること、同じ操作を二重に実行しないことなどです。新しい抽象化の利点が説明できず、確認範囲だけが大きくなる場合は、局所的な改善に留める選択肢を検討します。整った見た目を、互換性の証拠として扱わないようにします。

具体例で考える

架空の二つの保存処理を共通化すると、同じオブジェクトを共有する形になりました。

維持：入力を後から変更しても過去の保存値は変わらない。
検証：保存後に元の入力を変更し、保存先を確認。
論点：参照の共有と値の保存は同じではない。

通常の一回の実行では差が見えなくても、状態を再利用すると問題が表れます。内部の整理でも、状態の寿命が変わっていないかを確認してください。

確認課題と合格の目安

整理したい処理に、外部契約と共通化で得たい利益をそれぞれ三つ書いてください。

• 外部から見える変更を認識できる。
• 過去の入力やデータの互換性を保っている。
• 状態共有や実行回数の変化を確認している。