一段代码通常不是在某天突然变成”遗留系统”的。它更常见的路径是：第一个临时分支解决了紧急需求，第二个分支复制了这段逻辑，第三个团队不知道原有约定，于是加了另一个入口。每一步单独看都合理，合起来却让修改任何地方都变得危险。我在维护过几年的系统里反复看到这条路径——它几乎从不是某一次”写得差”，而是局部变更一次次绕过共同边界。

劣化的是共同理解

格式不统一、命名不好当然会增加阅读成本，但更严重的是边界失效：状态由多个模块同时修改；相似规则在三个地方各写一遍；调用者必须知道本不该知道的内部细节。

假设一个预约系统起初只有”创建”和”取消”。后来陆续加入改期、候补、批量导入和人工修正。如果每个新流程都直接改库存、通知和订单状态，短期很快，长期则没人能回答”什么动作会触发通知”。系统的问题不是文件多，而是规则失去了唯一的位置。

速度不是设计的对立面

“业务快，所以来不及设计”常常是真的；但这不等于只能放弃一致性。设计不是在开始前画一张永远正确的图，而是每次改动前至少回答：这条规则属于谁？新增分支会不会改变已有路径？不确定的部分怎样隔离？

在变化快的阶段，最值得保住的通常不是完整抽象，而是几个最低限度的约束：明确的所有权、可追踪的入口、少量关键路径的测试，以及能说清理由的例外。

用系统减速，而不是靠英雄主义

代码审查的价值不在于找标点错误，而在于让改动者解释边界；测试的价值不在于追求覆盖率，而在于保护不能被悄悄改变的行为；重构的价值也不在于”变漂亮”，而在于消除下一次必然复制的结构。

不必承诺把所有旧代码翻新。先找最常改、最常出错、最阻碍多人协作的一段链路，给它补上规则、责任和验证。代码不会永远保持干净，但团队可以让它不那么快失去可理解性。