7.4 技术债作为工程金融

技术债不是“我不喜欢的旧代码”。技术债是团队为了当前速度、验证或约束，接受了一个会在未来产生额外成本的技术选择。

债务本身不一定错。真正危险的是债务不可见、没有利息估算、没有偿还计划，却每天拖慢团队。

本金、利息和风险

技术债可以像工程金融一样分析：

• 本金：当初没有做完整方案而省下的成本，或现在要修复它的成本。
• 利息：未来每次开发、测试、发布、排障额外付出的成本。
• 风险：债务导致事故、安全问题、扩展失败或人员瓶颈的可能性。
• 到期日：外部法规、依赖废弃、业务增长或团队扩张带来的时间压力。

如果一个旧模块很稳定、很少改、也不造成事故，它可能只是旧，不一定是高优先级技术债。

合理负债需要记录

有些债是理性的。例如为了验证市场，团队先用手工运营流程；为了赶合规截止日期，先做保守实现；为了避免过早抽象，先接受少量重复。

理性负债要写清楚：

• 为什么现在借债？
• 省下了什么？
• 利息是什么？
• 哪个信号说明债务变危险？
• 什么时候偿还？

偿债要看组合

偿还技术债不应该变成“把所有旧代码重写”。更好的方式是维护一个组合，按利息、风险、成本和业务窗口排序。

优先考虑：

• 高利息：每天拖慢开发或发布。
• 高风险：可能造成安全、数据或稳定性事故。
• 低成本高收益：小修复能消除大量噪声。
• 阻塞未来：不处理就无法做重要功能。
• 接近到期：依赖停维、法规时间点、流量增长。

技术债管理的目标不是追求“零债务”，而是让团队知道自己欠了什么、为什么欠、什么时候还、如果不还会付出什么利息。