refactoring-analysis

リファクタリング分析

動作を維持しながら、実証された保守コストを削減できる変更を見つけてください。コードの臭い、その根拠となるソース、具体的な改善策を示してください。実際的な影響を伴わない、教科書的な分類だけでは指摘に該当しません。

1. 依頼と現在のコンテキストから対象範囲を判断します。広範な依頼の場合は、コードベースを把握し、依存関係やホットスポットを優先してください。対象が50ファイルを超えるという理由だけで、確認を求めて作業を止めないでください。サンプリングした領域や未調査の領域は明記してください。
2. 候補となるコードの臭いに関連する箇所を、references/code-smells-catalog.md と references/refactoring-techniques.md から確認してください。カタログのしきい値は判断材料であり、必ず編集する必要があるという意味でも、すべてのカテゴリで指摘を出す必要があるという意味でもありません。
3. 所有関係、結合、呼び出し元、公開境界を追跡してください。ドメインモデルに関する質問の場合に限り、references/solid-ddd-context.md を参照してください。通常のコードに SOLID の観点での確認は不要です。
4. 確認できた改善機会を、ユーザーへの影響、保守への影響、発生頻度、リスク、工数に基づいて優先順位付けしてください。影響の大きい項目については、変更前後の動作と、それを検証する仕組みを説明してください。既存のテストを活用してください。テストが不足しているからといって、すべてのレイヤーで新しいテストスイートを追加する必要はありません。
5. レポートを求められた場合、既定の出力先は docs/_refacs/<YYYYMMDD>-<slug>.md です。assets/refactoring-report-template.md を適用してください。限定的な依頼には、簡潔な回答を使用できます。必要に応じて、checklists/analysis-checklist.md を使って重要な引用と推論を確認してください。
6. ユーザーが監査のみを依頼した場合は、指摘事項を報告してください。すでにリファクタリングの許可を得ている場合は、改めて確認を求めず、選定した作業を続行してください。公開済みの互換性と無関係な変更を維持してください。