legacy-modernization

遗留系统现代化

对运行中的系统进行渐进式迁移。这里左右每项决策的约束是：系统正处于生产环境中，变更期间必须持续运行。

步骤顺序

步骤顺序比具体技术更重要——每一步都是为了让下一步安全进行。

1. 先刻画，再修改。 编写测试，锁定当前行为，包括错误行为。你不是在测试代码_应该_如何运行，而是在记录它_实际_如何运行，以便行为差异清晰可见。如果某条断言看起来不对，重点就在这里——把它写下来并说明：

   def test_domestic_lightweight():
       order = {"weight": 5, "destination": "domestic", "priority": False}
       # Current behaviour: nothing charged under 10kg. Looks like a bug —
       # pin it here, fix it as its own change after the migration lands.
       assert calculate_shipping_cost(order) == 0.0
   

   Golden-master 或 approval 测试（approvaltests、syrupy）能最快覆盖棘手的代码，因为它们会整体捕获输出，不需要你先理解代码。

   然后检查测试网是否真的牢靠：对你即将修改的代码运行变异测试工具。特征化测试套件往往看起来很全面，却仍会漏掉你即将改动的确切分支——存活的变异体会在事故发生前告诉你测试的盲点。

2. 插入接缝。 通过抽象实现分支：在要替换的对象上引入接口，并让所有调用方都通过该接口访问，同时仍委托给旧代码。这是一个可以单独发布和验证的无操作变更。

3. 在接缝后构建替代实现， 暂不启用或通过功能标志关闭。它还未处理流量，因此可以有问题。

4. 通过功能标志逐步切换流量——先内部用户，再一部分流量，最后全部流量。每一步都能在切换标志所需的时间内回退，这正是安全的关键。每次提升流量比例前，都要将回退触发条件明确为指标和阈值（“错误率超过 0.5%，持续五分钟 → 恢复到之前的流量比例”）。等问题发生时才决定什么算糟糕，只会让流量提升变成争论，而不是回退。

5. 只有当新路径已在生产环境中稳定运行足够长的时间，覆盖其慢速场景后，才删除旧路径——例如月末作业、季节性高峰、年度报告。过早删除，就会发现有一条没人记得的代码路径。

约定

• 不要进行大爆炸式重写。 重写要追赶不断变化的目标：旧系统持续发布新功能，而新系统还在奋力追赶。本指南中的现代化方案之所以都采用渐进式，是有原因的。
• 每一步都要能发布并可回退。 只有全部完成后才可行的迁移，没有安全的中止点——而漫长的迁移总会被打断。
• 对于计算金额或状态的功能，切换前先并行运行。 让新旧系统处理相同输入，比较输出，记录差异，同时继续提供旧系统的结果。能看见的差异，胜过客户报告的差异。
• 整体结构采用绞杀者无花果模式： 在前方设置门面，按功能将请求路由到新系统或旧系统，一次迁移一条路由，直到没有请求再到达旧系统，然后将其移除。
• 默认保留行为，包括错误行为。 下游总有某些部分依赖那些奇怪行为。应将其作为单独且明确的变更修复——绝不要把它们合并进迁移中，否则行为变化就会与迁移缺陷难以区分。
• 数据库迁移采用扩展与收缩模式： 添加新列，双写，回填，切换读取，然后删除旧列——每个阶段都能独立部署，且都与同时运行的代码版本兼容。
• 针对遗留系统编写的新代码仍须符合当前标准。 为了“一致性”而照搬周围代码的风格，只会让现代化后的遗留代码比开始时更多。