重构常被误解为“大改一次更干净”。实际上，越难描述当前行为，越应该先建立基线，再用可回滚的小步骤改善结构。
1. 明确不应改变的行为
列出输入输出、错误类型、接口格式、性能边界和兼容版本。对于历史代码，可先写特征测试记录现状。
2. 分离结构调整与功能变化
重命名、抽取函数和移动模块应与新功能分开提交，便于评审和回滚，也更容易判断测试失败原因。
3. 从依赖边界开始
先封装数据库、网络和文件系统等外部依赖，减少核心逻辑的隐式耦合。不要一开始重写所有内部实现。
4. 持续比较质量与性能
每个阶段运行测试、静态检查和关键基准。代码更漂亮但请求变慢或内存上升，需要重新权衡。
常见误区
- 重构中顺便改业务规则
- 没有行为基线
- 单个提交改动过大
- 只比较代码行数
执行检查清单
- 外部行为已列出
- 测试覆盖关键路径
- 提交可独立回滚
- 性能没有明显退化
总结
安全重构依靠可观察行为和小步反馈，而不是对新设计的信心。每一步都应让系统更容易理解，同时保持可用。