概述

定义

技术债是个比喻，自1992年被首次提出，后又经发展。如今，技术债既指团队有意走的捷径，又指许多损害软件系统的不良实践，还泛指复杂的问题。引用Ken的话说明技术债：“take shortcuts today with expense of tomorrow”。

分类

技术债有三种主要形式：幼稚的技术债、不可避免的技术债和策略性技术债。

幼稚的技术债指由于团队成员、组织或过程不成熟导致的不良实践，包括业务不成熟（需求过多，开发时间过紧），设计粗糙、缺陷、测试不足、手工测试过多、集成和发布管理不善等等。因为这种技术债常出于无意或者粗心大意，所以称为幼稚的技术债。幼稚的技术债可以通过培训和运用技术实践来预防。

与幼稚的技术债相反，不可避免的技术债天然无法预防。例如，完成重要冲刺并获得反馈后，团队对于业务领域的理解更加深入，团队需要随之更新早期所做的设计。又例如，第三方提供的组件修改接口，团队需要随之对应修改自己的组件。这类修改源于团队无法完美地预测未来，是不可避免的，称为不可避免的技术债。不可避免的技术债虽然无法预防，但可以减少负债。方法是通过频繁迭代，逐步加深对业务领域的理解，及时地、持续地对应修改设计和实现。

策略性技术债指当积累技术债所带来的受益大大超过债务成本时，组织有意选择去承担的债务。例如，组织为达成某个重要的债务目标而在软件设计和实现方面有意走捷径。它可以作为一种工具，帮助组织从经济角度量化技术债带来的弊端，从而对重要的、时效性强的决策做出理性判断。

技术债的危害

从产品角度看，技术债导致交付时间延长，缺陷数量可观，开发和支持成本上升。技术债有一个重要特点，它是以不可预测的非线性方式增长的。达到某个时间点，技术债到底某个“临界量”的时候，产品也就到达爆发点，变得非常混乱，无法管理。

从团队的角度看，在技术债的积累过程中，开发团队不得不硬着头皮挣扎，付出额外的劳动偿还技术债带来的利息。当债台高筑，整个软件系统复杂而混乱，新特性填不进去，缺陷越来越多。团队中由经验的技术高手陆续离开，另谋高就，走不掉的就像掉进一个泥潭，越陷越深，挫折感四处弥漫，团队表现越来越差。

技术债的起因

策略性技术债和幼稚的技术债通常都是迫于业务压力而必须满足某个迫在眉睫的、重大的最后期限而造成的。试图用减少测试的方式提高开发速率是错误的，不但不能真的提高开发速率，而且必将导致速率更低。技术债不加以管理，出现债累债，最终必然没有好结果。

技术债的管理

管理技术债的积累

在技术债方面，应使用好的技术实践停止向产品里增加优质的技术债。这里，好的技术实践指“测试驱动开发、自动化测试、持续集成、简单设计和重构等等”。在管理方面，应强化“完成的定义”检查列表的检查力度，指导团队在每个冲刺结束时，给出一个低负债或零负债的解决方案。在经济方面，量化背负经济债的经济效益，正确理解技术债经济。

可视化技术债

有三种方法使技术债在技术层面可视化：

第一、把技术债当作缺陷录入缺陷跟踪系统。这种方法的好处是开发团队使用熟悉的系统，需要注意的是，需要标记技术债，以便于单独查找。

第二、把技术债作为产品待办项加入产品待办项列表。这种方法适用于技术债偿还成本较高的情况，好处是对于产品负责人来说，技术债与新特性一样醒目，产品负责人可以参与调整技术债与新特性的优先顺序。

第三、创建一个单独的技术债列表。

偿还技术债

原则：并非所有的技术债都应偿还；应用童子军规则（有债就还）；先偿还高息技术债；分期偿还技术债；一边做有客户价值的工作，一边偿还技术债。

并非所有技术债都应偿还

一般来说，技术债要偿还，但在如下三种情况下，技术债可以不还。

行将就木的产品

如同人的生命一样，产品在市场上也有生命周期。一种产品进入市场后，会经历引进、成长、成熟、衰退的过程，销售量和利润会随时间推移呈现由少到多，再由多到少的过程，这就是产品的生命周期现象。那些步入衰退期的产品，既不需要开发新特性，也没有严重的缺陷需要修复。这时与其把宝贵的开发资源投入在偿还技术债上，还不如去开发新产品。

抛弃型原型

有时为了获取初步的用户反馈信息，需要创建只用一次就抛弃的原型，这样的原型可能欠下大量的技术债。但这种原型的价值不在于代码，而在于获得用户反馈。这样的技术债不必还。当然，如果在做出原型后，又决定留下它作为一个可演变为产品的演进原型，就肯定得收拾这个债台高筑的烂摊子。

短命产品

Ken举例，一个应用在金融行业的金融衍生交易系统，其生命周期只有三个月。在这三个月中，新产品迅速占领市场。三个月后，当竞争对手的跟风产品也推向市场的时候，组织让这个产品退市，把腾出来的资源使用在开发另一套新产品中。这样的短命产品，欠下的技术债可以不还。这是因为，虽然从技术角度看，上线一个设计和实现存在诸多问题的系统存在巨大的风险，但从商业角度看，抓住最佳时机，创造最高利润，不失为成功的决策。

应用童子军规则（有债就还）

偿还技术债需要花时间，有开发者抱怨说：“那不是我欠下的债，为什么我来还？”

在偿还技术债的策略中，Ken谈到了美国的童子军规则。这个规则对参加童子军露营的孩子提出要求：“离开营地时，要让它比你进去时更干净。”如果发现营地脏乱，就应该清理，不管罪魁祸首是谁。要有意识地为下一个露营队改善环境。

在技术债问题上，每次改动产品时，开发者都要尝试让产品的设计和实现更好，而不是更差。这么做不只对开发者自己有好处，更对整个开发团队和组织都有好处。

先偿还高息技术债

技术债多，一次还不完，需要排列优先级，先还高息技术债。以买房贷款做类比，你有商业贷款和公积金贷款，先还哪个？当然是商业贷款。为什么？商业贷款利息高。在技术债中，有些模块的代码需要经常被改动，目前这些代码已经复杂不堪。不重构，问题很严重。重构，好处很明显。这种模块里所欠的就是高息技术债。有些代码很少需要做改动，不重构问题不大，重构了好处也不明显。这种模块里所欠的就是低息技术债。用有限的时间做最有价值的工作，优先偿还高息技术债。

分期偿还技术债

尽量不设立专门的“技术债冲刺”。因为这种“技术债冲刺”是误导，它让人们以为，欠债没关系，反正以后可以找到专门的时间还债。于是本该在每个冲刺完成的工作，却堆积到不得不处理了再专门花一个冲刺处理，而本来应该用于开发新特性的时间，就这样被挤掉。冲刺最重要的意义在于交付客户价值。“技术债冲刺”不但不能从根本上解决技术债问题，还与Scrum交付客户价值的核心理念相违背。

一边做有客户价值的工作，一边偿还技术债

比如在开发某个特性的时候，涉及到几个C++文件的修改。那么，对于这几个C++文件而言，首先保证不添加幼稚的技术债，其次清除偶然发现的技术债，最后，也是最重要的，专门偿还出现在这几个C++文件中的目标技术债。

���