重构老代码的正确姿势：别一次动太多

接手一个遗留项目，代码烂到不想看。但直接重构可能比不改更危险。

先建安全网再动手

任何重构之前，先给代码加上测试。不需要覆盖全部逻辑，但核心路径必须有。没有测试保障的重构就是在换零件时没熄火——改坏了也不知道。如果代码没法写单元测试，就先写集成测试，至少保证主要功能跑得通。

小步提交

每次改动不超过一个层次。今天只给方法重命名、提取函数，明天只移动文件位置，后天再改数据结构。每次改完跑一遍测试、提一次 commit。出问题能快速回滚到上一个安全状态。

保持接口不变

重构内部实现时不要改公开接口。调用方不需要知道你的代码变没变——他们只要结果对就行。必要的时候加一层适配器，把旧接口映射到新实现上，分步替换。

识别不值得重构的代码

不是所有烂代码都值得重写。只运行一次的数据迁移脚本、即将下线的功能、三年没人碰的模块——重构它们的投入产出比太低。精力花在经常修改、每次改都让人头疼的代码上。