冻结式维护的适用与代价
冻结式维护针对的是利息可控、但偿还并不急迫的模块：停止新增功能，只修缺陷与安全问题，把利息计入观察清单。它的成立有两个前提——改动频率低，以及存在明确的替代路线图。冻结的价值在于把有限的偿还预算集中到高频热点模块，同时避免在即将被替换的代码上做无谓的结构调整。
规则与条件
| 规则 | 只修缺陷与安全问题，不再增加新功能 |
|---|---|
| 适用 | 改动频率低，且存在替代或被替代的明确路线 |
| 代价 | 团队需接受在过渡期内使用临时绕行方案 |
| 退出条件 | 替代完成即下线，或替代取消后重新评估 |
典型使用场景
- 即将被替换的老引擎：新实现灰度期间冻结旧模块的功能演进
- 低频维护模块：每季度一两次改动，重构收益低于成本
- 报表类批处理：业务形态稳定，缺陷修复即可满足需求
- 被新产品取代的旧入口：保留可用性，停止投入新能力
- 预算受限的季度：把有限产能集中到高频热点模块
冻结策略示例
冻结策略示例
# 模块：老对账引擎（每季度 1 到 2 次改动）
决定：冻结新功能，缺陷按严重度优先修复
替代：新引擎 Q2 灰度，Q4 全量切换
退出：替代完成后下线，剩余债务不再偿还
例外：业务强需求走替代路线，确有必要的例外需登记在案进入与退出条件
| 条件 | 判断依据 | 动作 |
|---|---|---|
| 改动频率低 | 近半年改动次数与工单量 | 纳入冻结候选 |
| 有替代路线 | 替代方案有时间表与负责人 | 冻结新功能，只修缺陷 |
| 无替代且高频改动 | 改动频繁且影响面大 | 进入偿还预算，不做冻结 |
| 替代延期 | 路线图滑期 | 重新评估冻结是否仍然成立 |
| 替代取消 | 方案被撤销 | 解除冻结，重新纳入常规维护 |
| 临时绕行积累 | 绕过旧模块的补丁增多 | 核对绕行方案是否有退出计划 |
冻结期内的新需求应走替代路线，确有必要的例外要登记在案：例外没有记录时，冻结会被一次次突破，最后既没有得到结构改善，也没有节省投入。
冻结的前提是利息可控。如果模块高频改动且每次改动都要绕行，冻结会让团队长期处在临时方案中，实际成本高于直接偿还。
落地检查清单
- 冻结决定写明了退出条件与替代时间表
- 例外需求有登记与审批路径
- 冻结期内仍保证缺陷与安全问题得到处理
- 替代上线后确认旧模块的下线动作