关于技术债务，做开发的同学对如下场景应该不陌生：
- 为了敢项目进度，详细设计、单元测试等过程就不写了，以后补
- 需求变化万千，原本架构设计无法满足新的需求，可是又不想动架构，于是绕过架构设计新增代码
- 旧的系统，没有文档、没有注释，维护困难
如上问题，我们如果不及时去修正，欠下的债务会越来越多，从而会导致代码臃肿、系统效率低下，我们可以用技术债务这个词来形容上面出现的系统的质量问题。
那什么是技术债务呢？行程的原因又是什么？如何去管理技术债务？
我们在项目管理学习时知道表示软件质量的三角形图，时间、成本和范围，如下图：
为什么质量要放在三角形中间呢？因为质量是其他三个因素平衡后结果的体现。比方说范围不减、成本不增加，又想节约时间走捷径，很显然，会影响到质量，这个质量，不止是产品质量，还有架构质量和代码质量。我们队这种质量的透支，就是一种债务，而技术债务，就是软件项目中对架构质量和代码质量的透支。
所以技术债务是有利息的，债务的利息，就是后续对软件进行新增修改的时候，需要额外的时间成本。当然，技术债务不一定是坏的，软件项目中，经常会刻意的欠一些技术债务，提升短期的开发速度，让软件快速推出，从而抢占市场；还有像快速开发模型，通过欠技术债务的方式快速验证，即使验证不可行，这笔技术债务也无需偿还。
技术债务产生的原因在重构一书中作者Martin Fowler把技术债务产生的原因分成了两个维度：
1.轻率(reckless)还是谨慎(prudent)
2.有意(deliberate)还是无意(inadvertent)
这两个维度正好可以划分成四个象限，如下图：
- 轻率/有意的债务
此象限，反映的是团队因为成本、时间的原因，故意走捷径没有设计、不遵守好的开发实践，对于债务没有后续的改进计划，比如，不做设计直接编码，后期也没有重构代码的打算，抑或团队过于年轻，没有足够的资深程序员指导和审查代码
- 谨慎/有意的债务
此象限，反映的是团队清楚指导技术债务的收益和后果，也制定了后续的计划去完善架构和提升代码质量的情况，比如为了尽快发布产品，先快猛糙的方式开发，后续进行代码重构，这种债务因为能及时偿还，所以可以短期有一定时间上的收益，长期也不会造成负面影响
- 轻率/无意的债务
此象限，反映了团队不知道技术债务，不知道后续要偿还技术债务的情况。
比如说一些开发团队对于什么是架构设计，什么是好的开发实践一无所知，代码一团糟
- 谨慎/无意的债务
此象限反映了团队很重视架构设计和技术债务，但由于业务的变化，或者其他客观因素造成技术债务的产生。比如说最初设计的时候，无法准确预测后面业务的发展，随着业务的发展，设计无法满足新的需求，这样产生的债务难以避免，但是如果能及时的对架构升级、重构，就能保证不会造成严重的影响。
如果管理技术债务呢？技术债务有利息也有收益，如何保证收益大于利息
Martin Fowler有过一张图，形象的描述了设计、时间和开发速度的关系，没有设计直接写代码，短期看是节约了时间，但是过了一个临界点后，开发速度是急剧下降：
所以我们最好能让技术债务控制在临界点之下，这就要求我们能充分了解目前项目中的债务情况，然后才好指定相应的策略，达到控制债务的目的。
如何识别债务
- 开发速度降低
- 单元测试代码覆盖率低
- 代码规范检查的错误率高
- bug数量越来越多
选择处理技术债务策略
- 重写：推翻重来，一次还清
优点：针对当前需求和业务发展特点，重新进行良好的设计，精简掉不需要的功能
缺点：重写通常工作量很大，新系统完成之前，需要对旧系统维护增加新功能，新写系统重新稳定也需要一段时间
- 维持：修修补补，只还利息
成本相对低，不用投入太大精力，但是如果项目不需要新增功能，只需要维护还好，如果后续维护家新增功能，后续成本会越来越高
- 重构：新旧交替，分期付款
重构相对是比较这种的策略，比较折中，每次改进系统的一部分功能，只对内部结构和代码进行重新整理和优化系统的结构，最终完全偿还技术债务，此方式有点多，不会导致系统不稳定，对业务影响小，但是整个过程耗时会很久
上面的三种策略没有绝对好坏，需要根据项目情况灵活选择，简单的选择原则就是看哪一种策略投入产出比更好
实施策略
- 对于重写，需要当一个正式项目来立项，按项目流程推进
- 对于重构，要把重构任务拆分成一个个小任务，放到项目计划中，创建成ticket，进行跟踪
- 对于维持，也需要把需要做的修补工作作为任务，放到计划中，进行跟踪
预防才是最好的方法
- 预先投资：好的架构设计、高质量代码就像一种技术投资，减少技术债务的发生
- 不走捷径：日常做好代码审查、单元测试代码覆盖率
- 及时还债：因为进度时间紧张等客观原因导致的走捷径，后续需要把这欠下的技术债务记下来，发到任务跟踪系统中，安排后续的开发任务重及时解决，可以避免债务越来越多。