用过渡兼容层控制重构范围，避免一次简单重构演变成持续数周的大工程

模块级别重构期间，一个容易被低估但非常关键的手段，是主动引入一批”过渡用的临时逻辑”（Adapter、Proxy、Wrapper这类适配层），这些临时代码的生存周期可能长达几个月甚至几年，看起来是”没什么必要”的额外工作，但它的真正作用是控制重构的传导范围。比如要修改一个函数的声明，如果直接改动这个函数本身，就必须同步找到并修改所有调用它的地方——而烂代码的典型特征之一正是模块间耦合度高，一个函数往往有几十处调用点，牵一发而动全身，一旦真的开始全面改造所有调用方，一次看起来很简单的重构很可能演变成持续好几周的大工程，而这种被迫扩大范围的重构往往是不可靠的（涉及范围越大，出问题的概率和影响范围也越大）。更稳妥的做法是加一层过渡模块：新旧两种函数签名同时存在，过渡层负责在新旧接口之间做适配和转换，这样修改函数本身时完全不需要同步改动所有调用方——调用方可以继续沿用旧接口，通过过渡层间接调用到新逻辑，等到后续时机合适（比如结合正常的需求开发顺带清理），再逐步把调用方迁移到新接口上，最终移除这层过渡代码。这个案例揭示了一条控制重构风险的重要技巧：当一次重构理论上需要”牵连”大量调用方才能完成时，不要被迫把这次重构的范围硬性扩大到覆盖所有调用方，而应该主动在新旧实现之间插入一层临时的适配层，把”核心逻辑的改动”和”调用方的迁移”这两件事在时间上彻底解耦——核心逻辑可以立刻改完，调用方的迁移则可以分散到未来更长的时间周期里、结合日常开发逐步完成，从而把一次原本高风险的大规模变更，拆解成一次小范围的核心改动加上多次分散、低风险的调用方迁移。