用途
该技能用于管理弃用与迁移。资料给出的核心前提是：代码是负债，不是资产。每一行代码都有持续成本，包括需要修复的缺陷、需要更新的依赖、需要打的安全补丁，以及新工程师的上手成本。弃用是移除不再产生价值的代码的纪律，迁移则是把用户安全地从旧实现转移到新实现的过程。资料指出，多数工程组织擅长构建，却不擅长移除，该技能正是针对这一差距。
何时使用
- 用新系统、API 或库替换旧的
- 下线不再需要的功能
- 合并重复实现
- 移除无人拥有但人人依赖的死代码
- 规划新系统的生命周期（弃用规划从设计阶段开始）
- 决定是维护遗留系统还是投入迁移
核心原则
代码是负债：每一行代码都有持续成本，包括测试、文档、安全补丁、依赖更新，以及任何在附近工作的人的心智负担。代码的价值在于它提供的功能，而不是代码本身。当同样的功能可以用更少的代码、更少的复杂度或更好的抽象提供时，旧代码就应当移除。
海勒姆定律使移除变难：当用户足够多时，每一个可观察的行为都会成为依赖——包括缺陷、时序怪癖和未记录的副作用。这就是为什么弃用需要主动迁移，而不仅仅是公告。当用户依赖的行为在新实现中不存在时，他们无法“直接切换”。
弃用规划从设计阶段开始：构建新东西时应该问：“三年后我们会怎样移除它？” 具有清晰接口、功能开关和最小暴露面的系统，比到处泄漏实现细节的系统更容易弃用。
弃用决策
在弃用任何东西之前，资料建议回答：
- 该系统是否仍提供独特价值？有则维护，无则继续。
- 有多少用户/消费者依赖它？量化迁移范围。
- 是否存在替代品？没有则先构建替代品，不要在无替代方案时弃用。
- 每个消费者的迁移成本是多少？可轻易自动化则做；手动且成本高则与维护成本权衡。
- 不弃用的持续维护成本是多少？安全风险、工程师时间、复杂度的机会成本。
强制式与建议式弃用
- 建议式：迁移可选、旧系统稳定时使用，机制为警告、文档、提示，用户按自己的时间线迁移。
- 强制式：旧系统有安全问题、阻塞进展，或维护成本不可持续时使用，机制为硬性截止日期，旧系统将在某日期前移除，并提供迁移工具。
资料建议默认采用建议式，只有在维护成本或风险足以证明强制迁移合理时才用强制式。强制式弃用必须提供迁移工具、文档和支持，不能只宣布截止日期。
迁移流程
第一步：构建替代品。替代品必须覆盖旧系统的所有关键用例，具备文档和迁移指南，并已在生产环境验证（而不只是“理论上更好”）。
第二步：公告与文档。资料给出的弃用通知示例包含状态、替代品、移除日期、原因，以及迁移指南（替换导入、更新配置、运行迁移验证脚本）。
第三步：增量迁移。逐个迁移消费者，而非一次全部。对每个消费者：找出与弃用系统的所有接触点；改用替代品；验证行为一致（测试、集成检查）；移除对旧系统的引用；确认无回归。资料提出“轮转规则”：如果你拥有被弃用的基础设施，你就有责任迁移你的用户，或提供无需迁移的向后兼容更新。
第四步：移除旧系统。仅在所有消费者迁移完成后：验证零活跃使用（指标、日志、依赖分析）；移除代码；移除相关测试、文档和配置；移除弃用通知。
迁移模式
- 绞杀者模式：新旧系统并行运行，逐步将流量从旧系统路由到新系统，当旧系统处理 0% 流量时移除它。资料给出 0%/100%、10%（金丝雀）、50%、100% 空闲、移除五个阶段。
- 适配器模式：创建适配器，把旧接口的调用翻译到新实现，消费者继续使用旧接口。
- 功能开关迁移：用功能开关让消费者逐个从旧系统切换到新系统。
- 数据库模式迁移（扩展/收缩）：资料指出模式变更是最危险的迁移，因为数据是唯一无法通过回滚部署来还原的东西。失败模式是把模式变更与代码变更耦合：在同一次发布中重命名列并开始使用新名称，在推出窗口期新旧代码同时运行，其中之一会查询不存在的列。解决办法是绝不在原地修改列，而是以增量阶段迁移，使新旧代码在每一步都有效。流程为：扩展（新增可空列，与旧列并存）→ 迁移（回填已有行，应用双写新旧）→ 收缩（当没有代码读取旧列后，在后续独立部署中删除它）。资料以把 name 重命名为 full_name 为例给出完整步骤：扩展添加可空 full_name 并部署；双写 name 与 full_name 并部署；分批回填 name → full_name，避免锁表；切换读取指向 full_name，保持双写，部署并观察；停止写入 name，然后在后续独立部署中删除该列。
规则包括：新增先行、破坏性操作最后且单独进行；每次迁移都要有经过测试的回退路径；回填要分批并避开热路径；大型索引要不阻塞写入地构建（如 Postgres 的 CREATE INDEX CONCURRENTLY）；风险高时用功能开关与代码解耦。
僵尸代码
僵尸代码是无人拥有但人人依赖的代码，不被积极维护、没有明确所有者，并会累积安全漏洞和兼容性问题。迹象包括：6 个月以上无提交但存在活跃消费者；没有指定的维护者或团队；无人修复的失败测试；无人更新的已知漏洞依赖；引用了已不存在系统的文档。应对方式是：要么指派所有者并妥善维护，要么用具体的迁移计划将其弃用。
常见合理化与反模式
资料列举了多种合理化及其现实，例如：“它还能用，为什么要移除？”——无人维护的可用代码会累积安全债和复杂度，维护成本会无声增长；“迁移太贵了”——应将迁移成本与 2-3 年的持续维护成本对比；“用户会自行迁移”——他们不会，需要提供工具、文档和激励，或自己完成迁移；“直接重命名列，就一行”——推出期间新旧代码同时运行，会有一方查询不再存在的列，应使用扩展/收缩而非原地重命名；“需要时再写回滚”——没有回退路径的迁移就是无法回滚的部署。
红旗信号包括：被弃用系统没有可用替代品；弃用公告没有迁移工具或文档；多年“软”弃用无进展；僵尸代码无所有者却有活跃消费者；向被弃用系统添加新功能；未测量当前使用量就弃用；未验证零活跃消费者就移除代码；模式变更与依赖它的代码在同一次部署中发布；在原地重命名或删除列；迁移合入时没有经过测试的回退路径，或回填会锁表。
验证清单
弃用完成后应确认：替代品已生产验证并覆盖所有关键用例；存在含具体步骤和示例的迁移指南；所有活跃消费者已迁移（通过指标/日志验证）；旧代码、测试、文档和配置已完全移除；代码库中不再有对已弃用系统的引用；弃用通知已移除。数据库模式迁移后应确认：变更以增量阶段发布（扩展 → 回填 → 收缩），而非单次原地编辑；每个部署步骤中新旧代码对模式都有效；每次迁移都有经过测试的回退路径；回填以限流分批运行；破坏性步骤（删除/重命名）在无代码引用旧形态后单独部署。
限制
资料未提供该技能的具体安装方式、命令、平台支持范围、收费或价格信息，这些事实暂未提供。