リファクタリング は何をしますか？
使用する場合
- ユーザーがリファクタリング、再構築、コード移動、モジュール分割または統合、インターフェース簡略化、段階的書き換え、依存関係逆転、重複コード除去を要求した場合。
- 変更が振る舞いを維持しながら構造を変更すると主張している場合。
- リファクタリングが複数の呼び出し箇所、パブリックシンボル、テスト、または所有権の境界に影響する場合。
使用しない場合
- タスクが構造変更を伴わない小さなローカルバグ修正である場合。
- ユーザーが明示的に振る舞いの変更を要求し、振る舞いを維持するリファクタリングを求めていない場合。
- リファクタリングするかどうかを決定する前に、より広範な設計レビューが必要な場合。
- 主要なリスク領域がまだ不明確であるため、最初のステップとして広範なエンジニアリングレビューが適切な場合。
ワークフロー
- 維持する振る舞いと変更する構造を定義します。
- 非目標を明示します。機能変更なし、互換性変更なし、エラーセマンティクス変更なし、明示的に要求されない限りパフォーマンスの主張なし。
- リファクタリングの影響を受ける呼び出し元、テスト、ドキュメント、設定、生成コード、パブリックインターフェースを調査します。
- 振る舞いが重要でカバレッジが弱い場合は、特性テストを追加します。
- 作業を、意味のある境界の間でコンパイルおよびテスト可能な、小さな可逆的なステップに分割します。
- 機械的な移動や名前変更を、セマンティックな編集から分離します。
- ユーザーが明示的に破壊的変更を要求しない限り、パブリックAPIを維持します。
- 呼び出し元の移行と振る舞いの確認が完了した後にのみ、古いパスを削除します。
参考文献
- 複数ステップのリファクタリングを計画する前に
references/refactor-playbook.mdを読んでください。 - テストが弱い場合や振る舞いを固定する必要がある場合は
references/characterization-tests.mdを読んでください。 - リファクタリングを最終決定する前に
references/review-checklist.mdを読んでください。
停止条件
- 維持すべき振る舞いが不明確である。
- リファクタリングを成功させるために広範な振る舞いの変更が必要である。
- ユーザーの明示的な承認なしに、パブリックAPI、設定、プロトコル、ストレージ、メトリクス、またはエラーセマンティクスが変更される可能性がある。
- 差分がリファクタリング、機能追加、パフォーマンス最適化、クリーンアップを安全にレビューできない方法で混在している。
出力ルール
- 変更されないままであることが意図された振る舞いを報告します。
- 機械的な変更をセマンティックな変更から分離して報告します。
- 振る舞いを保護するテストやチェックを報告します。
- 確認されていない振る舞い、互換性、またはパフォーマンスの側面を明記します。