代码弃用与迁移

代码退役为什么这么难

工程团队通常擅长构建系统，却鲜少擅长拆除系统。每行代码都附带持续的维护成本：修 Bug、更新依赖、修补安全漏洞以及新人 onboarding。当旧系统、API 或库不再具备性价比，或者出现无人认领却处处被依赖的“僵尸代码”时，直接宣布弃用往往只会引发生产事故。Hyrum's Law 告诉我们，只要用户足够多，任何可观测行为（包括 Bug 和时序怪癖）都会被依赖。因此，弃用不仅是发个公告，而是需要主动迁移的工程实践。

技能如何指导迁移落地

该技能将“弃用与迁移”拆解为可执行的判断框架与操作步骤。

• 弃用决策矩阵：区分 Advisory（建议性，允许用户按自己节奏迁移）与 Compulsory（强制性，需提供硬性截止日期与工具）。默认优先建议性弃用。
• 四步迁移法：先构建并在生产环境验证替代品；接着发布公告与文档；然后逐个迁移消费者（Churn Rule）；最后在确认零流量后移除旧系统。
• 渐进式模式：提供 Strangler Pattern（绞杀者模式）、Adapter Pattern（适配器模式）以及 Feature Flag 迁移等具体架构模式。
• Schema 扩缩迁移：针对数据库变更，强制要求 Expand/Contract 规范，禁止原地重命名或删除列，确保每一步均可独立部署与回滚。

适用边界与避坑指南

该技能并非万能的自动化脚本，而是一份需要工程师结合具体架构上下文做判断的工程检查清单。

• 它无法替你决定旧系统的业务价值，仅提供维护成本与迁移成本的对比视角。
• 数据库迁移的 Down 路径必须在合并代码前编写并测试完毕；大批量回填必须分批限流，避免锁表。
• 不要在弃用系统上继续开发新功能，所有投资都应流向替代品。