代码什么时候该重构，看这三个信号
烧烤店那个小程序的接口交付金额是 ¥3000，其中我手写的代码不到 20 行。剩下大量逻辑是 AI 按我的描述生成的，也是那次我开始认真想代码什么时候该重构。
快是真的快，但也很容易在同一个文件里堆出一种「每段都说得通、整体看不懂」的结构。
我就是从那个项目开始，认真对待代码什么时候该重构这个问题的。重构不是等代码烂掉再去救，是看到特定信号就动手。
一、先说结论：代码什么时候该重构，三个信号出现就该动手
我的判断标准收得很窄，只有三条：
- 改一个小需求，要动到三个以上不相关的地方
- 同一段判断逻辑，在项目里出现了第二遍
- 你开始不敢改某段代码，因为「说不清它会影响谁」
三条里中任意一条，就值得停下来处理。三条都中的时候，你已经欠了不少债。
顺便说一句，这三条都不是「代码不好看」类的标准。我从不因为代码风格去重构，只因为改动成本变高才动手。
二、信号一：改动开始「扩散」
现象很具体：你想加一个字段、改一个提示文案，结果发现要同时改接口、改校验、改展示，还得去改另一处看起来无关的逻辑。
原因通常是同一件事的规则被写进了多个地方。每多一处，将来就多一个漏改的点。
怎么处理：先把这条规则收成一处，再让原来那些地方都去调用它。不要一边加功能一边收规则，那是两件事，分开做。
收的时候注意一点：先确认这几处真的是同一条规则。看起来像但会分头变化的两处，硬合并会制造新问题。
三、信号二：同一段逻辑出现了第二遍
第一次写是正常的，第二次出现就是信号。
我自己的容忍度是：同一段判断逻辑抄到第二遍就抽出来，不管它有多短。因为第三遍一定会来，而那时候你可能已经忘了第一遍在哪。
这条规则的例外是：两处逻辑只是看起来像，但会朝不同方向变化。这种硬抽反而会把它们绑死，不如先留着，等第三次出现再判断。
四、信号三：你不敢改
这是最准的一条信号，也是最容易被忽略的。
判断方式很主观但很有效：如果你改一段代码前，需要先把整个文件读一遍才敢下手，那这段代码就该重构了。
恐惧来自不确定性——你不知道这个函数的调用方有几个、不知道这个字段有没有别处依赖它。这种不确定性本身就是结构问题，不是你的问题。
对应的处理方式也很朴素：先去把调用方找出来，把不确定性消掉。有时候找完你会发现，恐惧消失了，根本不用重构。
五、什么时候不该重构
有三种情况我会明确按住不动。
一是这段代码即将被替换，重构成了一次性投入；二是你手上没有验证手段，改完不知道对不对，这种情况先补验证再动（我在这上面栽过，另一篇写过三条路）；三是当前有更紧急的问题，重构不紧急，它只是重要。
重构的时机不是「我有空」，是「我接下来还要继续改这里」。
六、我实际的做法：小步，可回退
我现在的重构方式很保守：一次只处理一个信号，改完立刻验证，确认没问题再进下一步。
不会出现「重构三天然后一起测」这种操作，因为一旦出问题，你不知道是哪一步引入的。
重构的风险不在改动本身，在一次改太多。把步子切小，代码什么时候该重构这个问题就从一件可怕的事变成一件日常的事。
常见问题
Q：代码什么时候该重构，有没有客观标准？
A：可以用「改一个需求要动几处」来量化。如果一次小改动需要动到三个以上不相关的地方，就说明结构该整理了，这比凭感觉判断可靠。
Q：没时间重构怎么办？
A：不要专门排期重构，改成「下次改这里的时候顺手收一下」。这样不占用额外时间，也不会因为攒太久而变成一次大手术。
Q：重构和重写怎么选？
A：看现有代码是不是还值得留。如果大部分逻辑还能用、只是结构乱，就重构；如果连需求都变了，那其实是重写，别用重构的名义做重写。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」