代码重构：何时该重构、如何安全重构

重构是让代码保持可维护的关键手段，但做不好反而会引入新缺陷。核心原则只有一句：在不改变外部行为的前提下，改善内部结构。围绕这条原则，下面讲清楚何时该重构、以及如何安全地做。

一、先判断是否值得重构

不是所有「看起来不好」的代码都需要动。真正值得重构的信号包括：同一段逻辑在多处复制、修改一个需求要牵动十几个文件、模块之间依赖成环、新增功能越来越难落地。反过来，如果代码虽然不优雅但稳定、很少改动，就不必为了「整洁」冒险。

二、以测试为安全网

重构最大的风险是「以为没改行为，其实改了」。动手前先补齐覆盖关键路径的测试，让每次小改动都能立刻验证行为未变。没有测试的重构等同于改需求，失败时无法区分是重构出错还是原有缺陷暴露。

三、小步前进，频繁验证

把重构拆成一系列可独立验证的小步骤：一次只改一个结构问题，改完立刻跑测试、提交。小步的好处是每步都可回退，一旦测试变红，问题范围清晰可控。避免「大手一挥重写整个模块」，那往往是事故的开端。

四、五种常见的安全手法

• 提取方法：把一段过长逻辑抽出为具名函数，提升可读性。
• 提炼变量：为复杂表达式命名，消除重复计算。
• 搬移方法：把方法移到真正属于它的类，理顺职责。
• 以多态替换条件分支：把长 switch/if 链改为策略或子类，便于扩展。
• 引入接口隔离：拆分过大的接口，降低不必要的依赖。

这些手法都是机械化的、可预期的小变换，配合测试后风险很低。

五、不要把重构和修缺陷混在一起

重构的提交只做结构改善，修缺陷的提交只做行为修正，两者分开。混在一起会让代码评审难以判断哪些改动改变了行为，也让回滚变得危险。必要时先提交一个「只重构」的变更，再提交「只修复」的变更。

小结

重构是一项需要纪律的日常工作：有测试兜底、小步验证、手法标准、与缺陷修复分离。做到这几点，重构就能持续降低维护成本，而不是制造新的不确定。