我们不可能永远都在救火 —

一、定义

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的借鉴了财务债务的系统隐喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

二、分类

分成：低级技术债、不可避免的技术债和策略性技术债；

低级技术债：

指团队成员或业务人员不成熟或流程缺陷而导致设计粗糙、工程实践糟糕和测试不足。这些技术债是可以消除的，只要能够提供适当的培训，能够更好地理解技术实践的运用，能够做出合理的业务决策。其具备频繁偶发的本质；

不可避免的技术债,例如：

1 .事前.无法完美预测产品和设计随时间的推移需要如何演进。随着我们完成重要的认识循环并获得经验认知，可能需要修改早期做出的设计和实现决策。

2. 我们在产品中使用的一个第三方组件，该组件的接口随时间的推移而不断发展。他的一些改进引入了新的漏洞等，我们这个曾经让第三方组件很好运行的产品还是欠下了技术债，尽管我们自己没有任何过错。这种债务可以预测（随时间推移而改变组件接口，这样的假设合情合理），但无法避免，因为我们无法预见组件开发人员将来怎样进一步发展该组件。

策略性技术债：

组织从经济角度更好地量化和权衡重要的（往往时效性强）决策；例如：时效性强的产品推向市场；削减初期开发成本，把带有技术债的产品推向市场，等有收益之后再用自筹资金进行后续开发等；

一些常见的技术债：

● 不合适（糟糕）的设计——因为当前所用技术或业务发生重大改变，我们之前曾经有效的设计变得不再适用。

● 缺陷——我们已知但还没有时间解决的软件中的问题。

● 测试覆盖不充分——有些地方我们明明知道该做更多测试却没有做。

● 手工测试过多——实际该做自动化测试的时候我们还在做手工测试。

● 集成和版本管理不善——在做集成和版本管理的时候，采用的方式既费时又容易出错。

● 缺乏平台经验——例如，我们的大型机应用需要用COBOL来写，但身边精通COBOL的程序员却不多。

● 如此等等，技术债这一术语如今已被用于泛指任何一个复杂的问题。

三、后果

1.爆发点不可预期

不可预测的非线性方式增长，不确定哪根是压死骆驼的最后一根稻草。也许就是下一根！

交付时间延长

承担技术债意味着现在向未来申请借用工作时间。今天的债务越多，明天的速率就越慢。速率变慢，交付新特性和产品补丁需要的时间也变得更长。

缺陷数量巨大

技术债务状况严重的产品变得越来越复杂，因而也更难把事情做对。不同的缺陷盘根错节，以高得惊人的频率造成重大的产品故障。这些故障会对正常的增值开发工作流造成很大的干扰。另外，管理大量缺陷所产生的开销还会影响我们，使我们没有时间开发增值特性。

开发和支持成本上升

技术债一增加，开发和支持成本也会开始增加。过去一直简单又便宜，现在却变得复杂且昂贵。在债务状况越来越差的情况下，即使是小改动，也会涉及很高的成本。另外，技术债上升的成本还会影响我们做出继续开发特性还是修复缺陷时的经济决策。在低技术债状况下能够以低成本构建的特性（或要修复的缺陷），在高技术债状况下很可能需要高得多的成本。成本上升会导致产品更不适应其赖以生存的动态环境。

产品萎缩

对产品停止增加新特性或修复缺陷使其焕发活力，它对当前或潜在客户就会变得越来越没有吸引力。最后导致产品开始萎缩，不再是大多数客户愿意考虑的方案。仍然在使用产品的人往往也只是暂时接受现实。一旦有机会转到其他产品，他们多半就会转了！

可预测性降低

估算不准确，即使是最有经验的团队成员。面对一个负债累累的产品，需要花多少时间才能完成工作，未知数实在太多太多。最后导致的结果是做出承诺并为兑现承诺而建立合理预期的能力被大大削弱，引发不信任；

表现越来越差

随着技术债越积越多，人们开始预计工作表现逐渐越变越差，进而降低他们对结果的期望。当然，期望值降低顺着价值链开始蔓延，最终导致组织层面的整体表现越来越差。

挫折感四处弥漫

技术债不仅剥夺了技术人员的乐趣，也使业务人员不得开心颜。说得出却做不到的业务承诺，我们还能守多久？我们可怜的客户呢？他们还指望好好用我们这个债务累累的产品干活儿呢！他们很快会厌倦产品故障频频和我们的无能（导致一而再、再而三地出尔反尔）。价值链中曾经有过的信任被沮丧和怨恨取而代之。

客户满意度降低

随着挫败感增强，客户的满意度也会下降。因此，技术债伤害的不只是开发团队内部，甚至还包括整个开发部门。更糟糕的是，技术债所造成的后果严重影响到客户及其对我们的看法。

起因

前面说过，技术债有三种主要形式，它们的根源各有不同。不可避免的技术债，不管采取什么预防措施，都会积累。低级技术债是团队成员、组织及或过程不成熟所造成的。策略性技术债则是在债务累计收益大大超过债务成本时可能选择承担的债务。

如期完工的压力

策略性技术债和低级技术债通常都是迫于业务压力而必须满足某个迫在眉睫的重大最后期限而造成的。

试图以错误的方式提高速率

此时此刻，我们需要做出一个业务决策。是希望缩减范围以满足理想的发布日期，还是希望增加更多时间等到可能发布的日期再交付？不幸的是，业务人员往往都会否决这两种选择，而是强令团队必须在理想的发布日期交付所有特性。

按照这种提高的速率工作，团队必须做出慎重的决策，承担技术债（这意味着团队必须走捷径才能足够快速地工作以满足理想的发布日期）。或许设计差强人意，或许某些特定类型的测试（可能是负载测试）会被推迟。结果，积累下技术债。

债务积累

旧债如果不还，很快会积累新债。而且，一旦开始出现技术债，就会显示出不良经济后果。

版本2的实际速率比版本1更慢。显然，按照这个开发速率，我们肯定会再次错过目标发布日期。并且，业务人员再一次坚决要求，团队必须在理想的发布日期完成所有特性。结果，我们积累的技术债越来越多。

如果这个模式一直延续下去，速率线最后很可能会变平，表明系统的技术债已经多到使我们的有效速率趋于零的程度。最后造成的后果是我们不敢对产品轻举妄动，因为一处小的改动可能导致18个关联的地方出问题。更糟糕的是，我们根本无法预测哪18个地方会出问题。当然，我们没有什么超级测试框架可以帮助我们判断代码何时出错，但用不着担心，客户肯定会让我们知道的！