重构
使用时机
- 用户要求重构、重组、代码移动、模块拆分或合并、接口简化、阶段性重写、依赖反转或重复代码去除。
- 某项变更声称保持行为的同时改变结构。
- 重构影响多个调用点、公共符号、测试或所有权边界。
不使用时机
- 任务是无需结构变更的局部小缺陷修复。
- 用户明确要求行为变更而非保持行为的重构。
- 在决定是否重构之前，需要进行更广泛的设计评审。
- 由于主要风险领域尚不明确，恰当的第一步是进行广泛的工程评审。
工作流程
- 定义要保留的行为和要改变的结构。
- 陈述非目标：除非明确要求，否则无功能变更、无兼容性变更、无错误语义变更、无性能声明。
- 检查受重构影响的调用者、测试、文档、配置、生成的代码和公共表面。
- 当行为重要且测试覆盖弱时，添加特征测试。
- 将工作拆分为小的、可逆的步骤，在有意义的分界点进行编译和测试。
- 将机械性移动或重命名与语义编辑分开。
- 保留公共API，除非用户明确要求破坏性变更。
- 仅在调用者迁移且行为验证后，才移除旧路径。
参考资料
- 在规划多步骤重构之前，阅读
references/refactor-playbook.md。 - 当测试薄弱或行为需要锁定时，阅读
references/characterization-tests.md。 - 在最终确定重构之前，阅读
references/review-checklist.md。
停止条件
- 要保留的行为不清楚。
- 重构需要广泛的行为更改才能成功。
- 公共API、配置、协议、存储、指标或错误语义可能在没有明确用户批准的情况下发生变化。
- 差异将重构、功能工作、性能优化和清理混合在一起，无法安全审查。
输出规则
- 报告预期保持不变的行为。
- 将机械性更改与语义更改分开报告。
- 报告保护行为的测试或检查。
- 说明任何未经验证的行为、兼容性或性能方面。