技术债务最早是由Ward Cunningham提出的，当时是为了向非技术背景的项目干系人解释为什么要去做我们现在称之为“重构”的事情。Steve McConnell对技术债务的解释是：技术债务是短期的一种权宜，但从长期看相同的工作会比当前会费的成本要高很多。Jean-Louis Letouzey对技术债务的解释是：对不适合做法的补救成本的总和
关于技术债务，我们要重点讨论的是：
1) 技术债务的种类
2) 如何发现技术债务是否引发重大问题？
3) 处理技术债务的常用方法
4) 什么时候技术债务可以先暂缓处理？
技术债务的种类：
根据 Philippe Kruchten等人在 IEEE上面发表的文章，认为技术债务主要包括：
其中，
技术鸿沟（ Gap）是指最初的技术决定可能在当时是正确的，但是随着时间、市场、技术等不断改进，这个技术决定已经出现了很多的问题。
Martin Fowler提到了 22种代码异味，代码重复是很常见的一种。
如何发现技术债务是否引发重大问题？
Jean-Louis Letouzey认为，代码类型的技术债务，有一个量化的数据来考量债务程度： Bug反馈系数。 Bug反馈系数是修改 10个 bug，新注入（或者是衍生）出多少个 Bug？如果这个系数过大，则是个非常危险的信号。
BrainLink分享了 7个技术债务引起重大问题的危险信号：
1) 系统加载的时间越来越长
2) 某个模块缺陷率不断增加
3) 相同的问题在不同的模块或者组件中出现
4) 新的功能数量增加，引发新的 bug数量持续增加
5) 修复 bug的时间越来越长
6) 团队对某个模块或者组件抱怨很难理解或者很难测试
7) 某个模块的源代码频繁被修改， check－ in
处理技术债务的常用方法：
第一步：发现项目中包含哪些技术债务
第二步：把技术债务加到产品列表（ Product Backlog）中
第三步：根据债务造成的影响和修改债务的成本做优先级排序，这里是和业务需求一起整体排序
第四步：在不同的迭代中分阶段修改。
这里我们的几个具体实践是：
a) 我们会在技术债务的影响和快速交付的要求之间做平衡
b) 尽 量把最核心的技术债务在本次迭代完成，常用的是把技术债务作为技术需求对待，但我们也遇到过这样的情况：团队基于业务需求交付压力的考量，把技术债务在迭 代中消除基本是不现实的。在当前快速交付的前提下，很多团队会出现大量的技术债务。对于后者，我们的做法是：每三个迭代，休整一周（这一周的工作就是集中 消除关键的技术债务和学习债务）。
c) 技术鸿沟和架构债务，越晚修复成本越高，所以我们一般会增强团队中架构师的角色（无论是招聘还是短期合同工），同时增强架构和技术选择的评审，这些都会在迭代 0中进行，我们认为这些都是值得的。同时，我们在最初的几个迭代，独立的测试团队会集中测试架构是否可工作。
d) 代码复杂性、编码风格混乱等都是属于静态代码质量的问题，这些可以通过工具来解决，而不需要太多的人工评审。常用的静态代码检查工具有： Stylecop、 Fxcope、 Gendarme用于 C#开发； Checkstyle、 Findbugs、 PMD用于 Java开发
e) 每隔两天，会有一个 coding show的会议， 20~30分钟，每一个成员展示最核心的一段代码，快速评审，评审的重点是和规范不符的，编写质量较差的内容，然后及时修改。及时修正和全员共识是我们保证代码的手段之一。
什么时候技术债务可以先暂缓处理？
1) 上市时间的要求很急。我们要考量修改债务的成本和没有上市造成的损失。例如修改债务需要 1， 000元的成本，没有上市造成的损失是 100， 000元，还不包括客户潜在的转换成本，那就先不考量消除债务吧
2) 产品预算的限制。我们可以把债务后期的偿还费用，一直延迟到产品发布得到下一期产品投资为止。
3) 产品的生命周期很短。一些产品的生命周期很短，无论是对市场的认识不足，还是产品本身就是试探性产品。产品结束了，所有与之相关的债务也就消失了。很多时候，等看到产品的价值后再去偿还债务也是务实的。