リファクタリング スキル

動作を保持する構造化の変更です。目標は、同一の観察可能な動作を産生する異なる構造を実現することです。

このスキルなしでClaudeが陥りやすい過ち

リファクタリングの規律がないと、「リファクタリング」は構造化の変更、動作変更、および新機能を一度のパスで混ぜてしまいます。何か破損した場合、どの変更が原因かを知る方法がありません。リファクタリング中にテストが失敗するということは、スコープが大きすぎたことを意味していますが、一度に1つの変更を行う規律がなければ、エラーを分離することは不可能です。

動作契約

コードに触れる前に、観察可能な動作の観点から現在何をしているのかを述べてください。入力、出力、副作用などです。これが契約です。

リファクタリングがこれらのいずれかを変更する場合、それはリファクタリングではなく、機能変更またはバグ修正です。これらは別途対応してください。

1つ変更ルール

一度に1つの構造的変更を行います:

• 関数を抽出する
• 変数の名前を変更する
• 重複を削除する
• ネストを平坦化する
• クラスを抽出する
• モジュールを移動する

各操作後にテストを実行してください。パスしたら、続行します。失敗したら、その変更は何か破損しています。それを元に戻して、理由を理解してから進めてください。

バッチ処理はしないでください。「ついでに」改善を追加しないでください。名前変更と構造化変更を1つの変更で行わないでください。

カバレッジゲート

テストなしのリファクタリングは暗闇で家具を並べ替えるようなものです。最初の構造的変更の前に:

• テストスイートを実行する
• カバレッジを確認する
• リファクタリングされるコードのカバレッジが80%未満の場合は、最初にテストを書いて停止する

これはオプションではありません。これをスキップするということは、リファクタリングを検証できないことを意味します。

一般的なリファクタリング操作

操作	使用時期
関数を抽出する	コードのブロックが2箇所以上で使用されている場合、または単一の明確な責任を持つブロック
名前を変更する	名前が現在の目的を反映していない場合(これは動作を理解した後に行い、前ではありません)
重複を削除する	同じロジックが3箇所以上にある場合。ただし、ロジックが本当に同一の場合のみ、似ているだけではありません
ネストを平坦化する	単一の関数内に3レベル以上のネストがある場合
クラスを抽出する	関数またはモジュールが2つ以上の異なる関心事を処理するほど成長した場合
インライン化する	複雑さを追加するが明確性をもたらさない抽象化。直接的なバージョンの方が良い場合もあります

アンチパターン

理解していないコードをリファクタリングしないでください。それに触れる前に、その動作契約を述べることができるまで読んでください。

同じパスでバグを修正しながらリファクタリングしないでください。最初に修正してから、リファクタリングしてください。

テストがないコードをリファクタリングしないでください。最初にテストを書いてください。

変数名を推測で「改善」しないでください。現在の名前が間違っていることを理解した場合のみ名前を変更してください。

必須チェックリスト

1. 変更前にテストカバレッジが確認されたことを検証する
2. 構造的変更前に動作契約が述べられたことを検証する
3. テスト実行あたり1つの構造的変更のみが行われたことを検証する
4. テスト失敗が発生しても、完全に停止して再評価することなく進められていないことを検証する
5. すべての変更後にテストスイート全体がパスすることを検証する
6. カバレッジが低下していないことを検証する
7. すべての変更後も動作契約がまだ満たされていることを検証する