代码弃用与迁移指南

要解决的问题

在多数工程团队，上线一个新系统往往有清晰的路线图，让旧系统体面退场却常常无人负责。结果就是：僵尸服务还在跑、没人敢碰的模块越堆越多、同一个能力存在两份实现却没人记得为什么。很多团队把弃用理解为「发个公告」，以为写下 sunset date 就能自动完成迁移。现实中，用户会依赖未文档化的行为，迁移成本集中在少数高复杂度调用方，删除代码的动作本身又可能触发连锁故障。

核心能力与关键步骤

这个技能的价值在于把「下线旧代码」当成一项需要设计、度量和执行的工程任务，而不是一次管理层拍板。

它强调的几条原则：

• 代码是负债：每一行代码都需要测试、文档、安全补丁和依赖升级，当更少的代码能提供同样功能时，旧实现就该退场。
• Hyrum 定律让删除变难：只要用户足够多，连 bug、时序差异和副作用都会被依赖，因此弃用必须有主动迁移计划，不能只靠公告。
• 生命周期前置设计：新建系统时就问一句「三年后怎么把它删掉」，接口越干净、feature flag 越完整、暴露面越小，未来退场成本越低。

具体决策时，它会引导你依次回答：

• 这套系统是否仍在提供独特价值，还是只是「还在跑」？
• 有多少调用方依赖它，迁移范围如何量化？
• 是否已经有可替代方案，没有就先别急着下线。
• 每个调用方的迁移成本有多高，能否用自动化工具链降低？
• 继续维护的安全风险、工程师时间和心智负担是否已经超过迁移代价？

迁移过程中通常还需要：埋点观测真实调用量、分批推进调用方改造、灰度切换并保留可回滚路径，直到旧路径调用量归零再真正删除。

适用边界

它不是自动重构工具，也不会替你扫描仓库找出该删的代码。能否用好，取决于团队是否具备可识别的依赖者清单和明确的替代方案。如果某个系统还承担合规或财务等无法简单迁移的职责，更需要先评估风险再决定是维护还是重建，而不是按流程直接弃用。对于完全没有使用者的孤立原型，直接删除往往比走完整迁移流程更划算。