代码退役与迁移

要解决的问题

大多数工程团队擅长构建系统，却很少擅长删除它们。代码不是资产，而是负债——每一行都需要测试、文档、安全补丁和依赖更新。当旧系统、API 或库不再提供独特价值时，团队面临一个常见困境：继续维护一个越来越大的遗留代码库，还是冒险迁移到新方案。

更棘手的是 Hyrum 定律：只要用户足够多，每一个可观察的行为都会被依赖——包括 bug、时序怪癖和未文档化的副作用。这意味着发布一个 deprecation notice 远远不够，用户不会自动切换。

技能如何工作

这个技能围绕三条核心原则展开：

• 代码即负债：评估代码的价值在于其提供的功能，而非代码本身。能用更少代码、更低复杂度或更好抽象实现相同功能时，旧代码就该退场。
• 主动迁移而非被动宣告：因为 Hyrum 定律的存在，弃用需要主动推动用户迁移，而不是发公告了事。
• 设计期即规划退役：构建新系统时就要问「三年后怎么移除它？」——干净的接口、特性开关和最小暴露面能让未来的退役成本大幅降低。

技能覆盖的典型场景包括：替换旧系统/API/库、下线不再需要的功能、合并重复实现、清理无人认领但人人依赖的死代码，以及在设计阶段规划新系统的生命周期。

在做出弃用决策前，技能会引导你回答一组关键问题（资料中截断部分暗示包含成本、依赖、迁移成本等维度），并按步骤推进迁移流程。

适用边界与注意点

并非所有代码都该立即退役。对于仍承担关键业务、有活跃维护者且缺乏替代方案的系统，盲目迁移可能引入更大的风险。此外，迁移的成功取决于对用户依赖行为的充分调研——没有调研用户实际用法就宣布弃用，往往是灾难的开始。建议在启动迁移前，先用日志、指标或用户访谈确认真实依赖面。