小张刚接手一个老项目，页面卡顿、改个按钮要调5个文件。他一拍桌子：必须重构！结果开发到一半，产品经理跑来说：下周就要上线新活动页——重构还继续吗？
重构不是“重写”，但真会拖进度
重构（Refactoring）是改代码结构、不改功能。比如把重复的登录逻辑抽成一个函数，把嵌套三层的 if 挤成一层 switch。它本身不加新功能，也不修 bug，但要花时间——而且常常比预估的多。
常见踩坑点：
• 以为“只动逻辑，不动界面”，结果改完发现某个弹窗样式崩了，回溯半天才发现是 CSS 里写了 .btn:hover { opacity: 0.8 }，而新 JS 给按钮加了 class 动态切换，触发时机变了；
• 把旧函数 A() 拆成 A1() 和 A2()，但忘了某处用 require('xxx') 引的是整个模块，没导出新函数，打包直接报错；
• 在 Vue 2 项目里把 options API 改成 Composition API，结果团队里两位同事还在用老写法，合并代码时冲突频发，光 resolve 就花了两天。
什么情况下重构反而能抢回时间？
上个月我帮朋友公司救急：他们有个订单导出功能，每次导 1000 条就超时。原代码是 for 循环里每条都查一次数据库，再拼 Excel。重构时改成批量查询 + stream 写入，单次导出从 42 秒压到 1.7 秒。上线提前了两天——因为不用再临时加服务器扩容，也不用反复压测调优。
关键判断点：
• 原代码已明显成为迭代瓶颈（改一个小需求要改七八个地方）；
• 当前上线任务和重构范围无直接耦合（比如重构的是用户中心模块，而上线的是首页 Banner）；
• 团队对改动有共识，且有人熟悉这块旧逻辑（避免边读边猜，边猜边错）。
上线前一周，还能不能动重构？
能，但得“切片”。别想着“一口气干掉所有屎山”，试试这样操作：
1. 锁定最小可验证单元，比如只重构 calculateDiscount() 这个函数，输入输出不变，内部全重写；
2. 补上单元测试（哪怕只有 3 个用例），确保改完后 9.9 折、满减、会员价算得和原来一模一样；
3. 提交 PR 时标注清楚：“本次仅重构计算逻辑，不影响任何 UI 和接口，可随时回滚”。
我们试过在上线前 3 天重构支付回调验签部分。原代码混着日志、加密、参数校验，改一处崩三处。重构成三个独立方法后，不仅当天测通，后续接入微信分账也只加了两行调用——因为验签逻辑已经稳如磐石。
重构不是上线的敌人，而是你手里的扳手。拧松锈死的螺丝时，确实要停一下机器；但拧紧之后，下一次换零件，快得多。