重构原则：何时重构、何时不重构、重构的节奏与流程

重构这件事，说白了就是在不改变代码外在行为的前提下，把内部结构理顺。听起来简单，但什么时候该动手，什么时候该忍住，这里头门道不少。我见过太多团队，要么从不重构直到代码烂成一锅粥，要么天天重构结果功能一个都发不出去。

这一章，咱们就聊聊重构的时机、节奏和流程。嗯，都是我在项目里踩过坑之后总结出来的。

什么时候该重构？

我个人习惯，遇到下面这几种情况，就会主动考虑重构：

• 代码散发着坏味道——比如方法太长、类太大、参数列表冗长、重复代码遍地都是。你读代码的时候觉得「这写的什么玩意儿」，那就是信号。
• 添加新功能变得困难——本来加一个小需求，结果要改七八个文件，还担心改出 bug。这时候说明原有结构已经扛不住了。
• 代码审查时频繁出现相同问题——如果每次 review 都在说「这里命名不好」「那里逻辑耦合」，说明需要系统性地清理了。
• 你理解了更好的设计方式——有时候你写的时候没想清楚，后来突然明白了。这时候不重构，后面只会更痛苦。

什么时候不该重构？

重构不是万能药。有些时候，忍住不动反而是更明智的选择。

• 代码马上就要被重写或废弃——如果这个模块下个月就要被替换掉，别浪费时间去重构它。我曾经在一个即将下线的老系统上花了三天重构，结果上线前一天被告知整个系统要迁移……白干了。
• 项目截止日期临近——重构会引入风险。在 deadline 前一周大规模重构，基本等于给自己挖坑。这时候，能跑就行。
• 没有足够的测试覆盖——重构的前提是你能验证行为没有改变。如果没有自动化测试，重构就像蒙着眼睛拆炸弹。我建议先补测试，再动手重构。
• 团队对重构目标没有共识——你一个人重构，别人看不懂，合并时冲突不断，最后代码反而更乱。重构需要团队一起认可方向。

重构的节奏：小步快跑

重构最忌讳的就是「大干一场」。我见过有人打开一个文件，然后开始改，改着改着发现依赖的另一个文件也要改，然后越改越多，最后三天过去了，代码还没跑起来。

正确的节奏应该是：

1. 每次只改一个点——比如只重命名一个变量，或者只提取一个方法。
2. 改完立刻测试——确保行为没有变化。
3. 提交代码——小步提交，每个提交只做一件事。
4. 重复——继续下一个点。

你想想看，这样做的最大好处是什么？如果某个步骤出了问题，你只需要回滚最近一次提交，损失很小。而且代码审查的人也容易理解你在做什么。

重构的流程：一个可复用的步骤

下面是我在实践中总结出来的重构流程，你可以直接拿来用：

步骤	做什么	注意什么
1. 确认目标	明确这次重构要解决什么问题	不要同时做多个目标
2. 确保测试覆盖	写测试或确认已有测试足够	测试要覆盖核心路径和边界情况
3. 识别坏味道	找到具体的代码问题	用工具辅助（如 lint、复杂度分析）
4. 应用重构手法	提取方法、移动字段、拆分模块等	一次只做一种手法
5. 运行测试	确保所有测试通过	如果失败，回退上一步
6. 提交代码	写清晰的提交信息	说明做了什么、为什么做
7. 回顾	检查是否达到目标	如果没有，继续下一轮

这个流程看起来简单，但真正做到位并不容易。尤其是第 2 步，很多人会跳过。我刚开始也这样，觉得「这么简单的重构，不用测试了吧」。结果有一次改一个变量名，忘了改另一处引用，线上直接报错。从那以后，我再也不敢跳过测试了。

知识体系：重构决策全景图

下面这张图，把重构的时机、节奏和流程串在了一起。你可以把它当作一个决策参考：

最后说几句

重构不是一次性的活动，而是一种持续的习惯。就像整理房间，你每天花几分钟收拾一下，房间就不会乱到需要大扫除。代码也是一样。

我个人习惯，每天下班前花 10 分钟，把当天写的代码快速过一遍，看到明显不顺眼的地方就顺手改掉。这个习惯坚持下来，代码质量会慢慢提升，而且不会占用太多时间。

记住一句话：重构的节奏，应该是像呼吸一样自然，而不是像抢救一样紧急。