如果管理技术债务

技术债务的标准定义是什么？

下面是我比较认可的定义：
Technical Debt is the cost of fixing structural quality problems in
production code that the organization knows must be eliminated to
control development costs or avoid operational problems.
中文翻译如下：
技术债务是修复已上线程序中结构质量问题的成本，如果这些问题不解决，组
织清楚其带来的后果：后续升级开发失控或用户操作失灵。

常见的债务来源有以下几个。
进度压力逼迫开发团队走“捷径”，如程序中不写注释，造成后期理解的困难；测试不充
分，导致产品中存在操作隐患等。
设计团队做了不恰当的设计决定，如过早地选择了某个通信模式，后期的应用开发中发
现需要用不同的协议，由此带来了不必要的返工。
在修复缺陷或根据新要求修改代码的时候未识别出程序其他需要修改之处，造成软件产
品中的不一致。
用户故事没有得到足够的分解。分解是解决复杂问题、减少隐患的有效方法。要保证用
户故事被分解到足够小的单位，使每个代码函数及类的规模也都足够小。没有做到这一
点，就会造成后期的返工。
没有对复杂的、有依赖关系的技术文档、代码进行互查或评审。在一个迭代周期内，如
果评审、互查从来没有出现在敏捷白板的任务列表里的话，也会增加本次迭代隐患植入
的可能性。
缺少必要的系统文档支持。其后果是使得代码和其他技术文档产生不一致，也为以后的
开发、维护、升级埋下了隐患。
没有把不增加技术债务作为每次迭代“完成”的条件之一。这就给团队走“捷径”开了绿灯。
这里应该说明的是，有些技术债务也是可以的，毕竟它能够加快开发速度。就像我们用
信用卡借钱花一样，有时候我们确实需要超前消费。关键是要及时还款，否则利息会压
垮我们！
就像Ward Cunningham讲的那样：
为加快开发速度产生些债务也是可以的，只要能及时优化还债……当这些债务
没有被及时归还、处理时，风险就来了。花在那些没有写得太好的代码上的每
一分钟都是这些债务的利息。
华为把技术债务称为“带病开发”，我认为十分形象，说到问题的根子上

​    ​技术债务的分类。
下面是一些技术债务分类的例子：
意识到的债务或没有意识到的债务；
短期债务或是长期债务；
慎重考虑的债务或是不顾及后果的债务；
战略性的债务或是非战略性的债务。

技术债务的偿还。
下面是一些减少技术债务的优秀实践：
代码重构；
测试驱动开发；
代码评审；
结对编程；
持续集成；
编码规范；
增量设计。
    ​减少技术债务的具体步骤
虽然我们会努力控制技术债务，但如前所述，它依然不可避免。根据Vinay Krishna和
Anirban Basu（2012）提出的减少技术债务的13个步骤，我重新做了梳理、优化。如
果以往借的技术债务让团队举步艰难，那么不妨借鉴下面的13步流程。
（1）确定能投入到减债的时间。为了保证产品按时发布，Scrum团队需要计算出每天
（假设每天工作8小时）必须花费的开发新需求的时间（如5小时），在此基础上，算出
能花在评审及代码重构上的时间（如3小时）。
（2）了解代码的问题所在。重点是了解团队开发出的多余代码，以及不规范、有隐患
的代码。在进度压力大的情况下，这个工作比较难做到常态化。实践证明，后面步骤提
到的预防措施会更加有效。
（3）根因分析。分析为何有超前（实现用户故事外的要求）的代码，隐患植入的原因
是什么，如何规避类似问题。
（4）优化超前实施。超前实施在某种意义上来讲是预测客户需求，需要整个团队考虑
各种因素来确定，一般来讲一定要避免仅仅由团队去假设客户将来的需要！仅由开发预
测未来需求，一般意味着麻烦！
（5）尽量寻求帮助。哪怕没有实施结对编程，也应该鼓励相互沟通。你的问题很可能
其他人已经经历过，有问题一定要让大家知道，以寻求帮助。
（6）避免盲从。兼听则明，偏听则暗，团队需要多听然后做自己的选择。
（7）遵循最佳实践及编码规范。监控检查需要工具，业界有许多这类工具，包括开源
工具。如果没有工具，规范不能太多，也许规范要减化成编码军规！军规包含最重要的
编码要求。
（8）对超前代码做重构。团队需要完成一个模块的重构后，再做下一个模块，不要同
时对多个模块做重构。
（9）有效使用减债时间。如果在某个迭代中，团队提前完成了迭代计划的任务，那么
可以考虑用剩余时间做些还债工作。当然一定要考虑第一步的时间规划！
（10）自我管理技术债务。团队需要在每个迭代都关注债务的积累情况，安排优化工
作，也就是决定由谁做、做多少、在哪些代码模块做。
（11）关注效率提升。团队需要持续跟踪迭代速率，如前图所示，它的变化有可能暗示
债务失控。
（12）学习使用重构技术。所有开发人员都需要接受重构方法技巧培训，并在开发中不
断学习提升。
（13）持续学习，持续改进。在每个回顾会上，技术债务管理应该是一个常态话题。

技术债务的度量
近来业界提出了一些复杂的技术债务度量，这些方法很难真正被团队使用。其实一些简
单的度量就可以刻画出债务状况，例如：
上线时发现的缺陷数；
维护中新功能开发的平均时间；
上线后修复缺陷的平均时间。
这些指标的增加，意味着技术债务的增加。
技术债务很难被量化，Israel Gat将其转换成钱。如修复5万行代码需要10万元的话，那
么每行代码的代价就是2元。用这个方式和高管沟通技术债务，容易引起他们的关注。
如果使用这种方式度量债务，团队可以设定一个贷款限额（credit limit），当债务超出
这个值的时候，也许你就不能再开发新功能了，需要静下心了还债了。