公司里那个用了八年的后台系统，每次改个按钮颜色都像在拆炸弹——谁也不知道点保存会不会把整个订单模块搞崩。这其实就是典型的历史代码困境：没人敢动，但又不得不改。
别一上来就重写
很多新人看到老旧代码第一反应是“全部重写”。可现实是，老板不会为“代码更好看”批两周工时。更实际的做法是带着明确目标进场：比如“把用户登录迁到新鉴权体系”。目标越小，风险越低，也更容易获得团队支持。
先给代码套上测试枷锁
没有测试覆盖的重构等于高空走钢丝。不用追求100%覆盖率，先针对你即将修改的函数写几个关键用例。比如一段计算折扣的老逻辑：
function calcDiscount(price, level) {
if (level === 1) return price * 0.9;
if (level === 2) return price * 0.8;
return price;
}哪怕只写两条测试验证VIP和普通用户的返回值，后续改动时心里也能踏实不少。
提取比修改更安全
直接修改原函数容易引入隐藏bug。更好的方式是新建一个calcDiscountV2，把新逻辑放进去，原函数暂时保留只是调用新函数。这样一旦出问题，回滚只需要改一行调用。
用中间层隔离腐烂代码
有些DAO层直接拼SQL字符串，字段硬编码满天飞。与其冒险清理它，不如在它前面加个服务层。新功能全走新接口，老接口只修bug不加功能，慢慢让它自然淘汰。
注释不如埋点自证
遇到看不懂的“魔法数字”，别急着删。先打日志记录它的出现场景。有次我发现一个status===7的判断，查遍文档都没说明，结果上线后监控发现来自某个废弃渠道的补单脚本——这种信息比任何注释都有力。
让重构变成日常习惯
每次修bug顺手把紧挨着的if嵌套拆平一点，新增字段时顺便统一下命名风格。积少成多，半年后再看，那些曾经令人头皮发麻的文件也会变得能读了。