#技术债务治理

技术债务是软件开发的隐形杀手。它不像业务 bug 那样立刻可见，却会在某个不经意的时刻，以一次严重的线上故障、一段无法维护的代码、一次超乎预期的延期，狠狠还上利息。

但债务本身不是问题。问题在于：不知道欠了多少债、不知道什么时候该还、不知道怎么还才能不影响业务。

#什么是技术债务

Ward Cunningham 在 1992 年首次提出技术债务的比喻：软件中的技术债务就像金融债务，欠债是有代价的——你需要支付「利息」，也就是额外的维护成本和开发成本。

债务的来源有两种：

故意欠下的债务——为了赶 deadline、有意选择技术折中方案，清楚知道未来需要重构。这是合理的商业决策。

无意欠下的债务——设计不当、代码质量差、缺少测试、没有文档。团队对债务没有清晰认知。

#债务治理的四个步骤

本节围绕四个核心问题展开：

• 债务量化方法 —— 如何让债务可见、可衡量
• 债务优先级评估 —— 先还哪些债
• 重构策略选择 —— 用什么方式还债
• 增量重构实践 —— 如何在不影响业务的情况下还债
• 遗留系统现代化 —— 面对老系统的正确姿势

#债务治理的核心原则

债务可视化是第一步。一个团队如果不知道自己的债务规模，就无法做出正确的重构决策。债务量化不是为了追求精确，而是为了让团队对现状有一个统一的认知。

债务要分类管理。不是所有债务都需要立刻还。高息债务（影响开发效率、频繁引发故障）要优先处理；低息债务（性能稍差、代码不够优雅）可以暂时放着。

持续偿还比一次性清零更健康。债务治理的目标不是「消灭所有债务」，而是将债务控制在团队可以接受的范围内，并在日常开发中持续偿还。