技术债是什么?
在金融领域通过短期的借贷获得充足的资金加快发展，代价就是除了本金之外还要付出利息。软件领域也一样。
技术债1992年被沃德·坎宁安提出来。他首次将技术的复杂比作为负债，简称技术负债（技术债）。
技术债本身是对项目或者代码质量的重要衡量指标。
不稳固、脆弱的代码实现所引发的债务负担，会使整个工程组织陷入裹足不前的艰难境地！
由于项目的工期限制或产品抢占市场的时间窗口等原因，允许暂时不顾代码质量稍微欠点技术债可以快速将产品推向市场。
但很重要的一点：从现在开始就要及时重构偿还技术债，而不是以后再重构
如果不偿还技术债，在后续不断的迭代中，又将会在原来的技术债上引入更多的技术债，直到有一天在一团乱麻的代码上哪怕增加一个小小的需求都会带来极大的代价。
技术债是如何产生的
产品经理
- 我们必须马上上线
- 今天下班前必须完成
- 已经答应客户月底给了
- 人员流动太大
- ......
研发人员
- 不合适的设计
- 缺乏平台经验
- 复制-粘贴式开发模式
- 试图以错误的方式提高效率，
- 试图减少测试提高效率，比如单元测试、集成测试、系统测试、白盒测试、黑盒测试不足
- 人员技术水平不足
- 业务不熟悉，设计错误
- 代码太乱，没办法写单元测试
- 先赶进度，后面再重构
- 先用临时方案处理
- 手工测试过多
- 集成和版本管理不善
- ……
埋下的坑越来越多，相应的踩坑的命中率也越来越高。
技术债的后果
- 爆发点不可逾期
- 交付时间延长
- 缺陷数量可观
- 开发和支持成本持续上升
- 产品萎缩
- 可预测性较低
- 表现越来越差
- 挫败感四处弥漫
- 客户满意度降低
- ......
技术债的恶性循环
首先，技术债越来越多会不断地降低开发效率，进而导致需求响应慢，每加一个功能都困难重重，进而拖慢业务进度。
之后，业务上的挫败感会给程序员自身带来更大的挫败感。
再之后，团队开始无休无止的争论，有人要推到重来，有人害怕风险。
在这之后，长期技术不升级导致技术落后（极端的情况是连第三方库都不敢更新版本），这个团队的技术竞争力下降，每个人都能感受到团队无论是技术能力还是商业价值都在下降，进而导致更大的挫败感。
最终，上面这些问题还是会反过来影响业务，影响商业价值，让整个团队陷入恶性循环之中，最怕人才流失，又让新人更难融入。当团队(公司)业务(商业)价值降到最低的时候，也就是宣告解散(破产)的时候。
解决技术债的方案
推倒重来
一个很老的无法维护的遗留系统，也许最好的办法是整个重写。此时，最好有一个具备项目管理能力的SE操刀负责，因为此类项目一般耗时较长，复杂度较高，如果没有一定的技术和风险管控能力，最后的结果很可能花了大量的人力物力，最后却不了了之。
鉴于推倒重来，有较大的夭折风险，重写时一定要慎重，如果在一个公司中，很多项目特别是上线刚一两年的项目都在重构 ，则需要警惕：一、是不是必须整个重写；二、团队是否具备推倒重来的能力。
水滴石穿
向后兼容的不断迁移 新做一个系统兼容老的功能，或者直接在老的系统中直接加入新的流程，在测试用例的保证下，将功能随着业务升级一点一点的迁移，慢慢放弃老的系统，删掉代码，最后完成整个升级，将技术债像手术一样切除掉。
此方式的好处是：
- 脚踏实地，各个击破：分期偿还技术债，每次优化都是基于稳定的系统上
- 及时反馈，弱化风险：每个迭代的重构，都有坚实的测试覆盖，及时发现并修复引入的问题
- 持续响应，逐步优化：短期价值与长期价值齐头并进，一边做有客户价值的工作，一边偿还技术债
附：
技术债分类详情
文档负债
需求分析负债
不懂需求分析的软件开发工程师不是好的软件开发工程师，遇到问题一定要与上级领导或者客户及时反馈，及时沟通，某些需求不能做就是不能做，要持有一种质疑的心。找正确的途径去反馈问题而不是背地里去发恼骚，要懂得有效的沟通方式，如果软件开发工程师没有理解好项目需求而盲目开发项目，必然导致领域业务与开发业务不匹配， 从而付出更多的时间与精力去开发项目。
开发文档负债
软件开发文档不齐全，或者是软件文档功能与项目代码功能不一致。
一种是项目没有制定开发文档。没有制定代码规范文档，接口文档等相关技术文档。光看代码不看文档就够辛苦了，即使语义化变量名与函数名，也难易快速理解。（少见）
一种是项目没有更新开发文档。项目开发初期还有文档，后来文档没有对应没有更新，因为有些需求几乎都是临时新增的，导致后期项目迭代的时候就造成大量的冗余代码。（常见）
软件开发文档是项目最系统最全面的反映，看文档比看代码更容易理解项目的功能模块。
测试文档负债
体现于软件测试覆盖率低，测试用例不足。
在大多数的企业中，为了控制人力成本，软件测试都是由软件开发工程师去完成，而不是由专业的软件测试人员去负责，这样做往往会忽略了一些软件漏洞（当局者迷，旁观者清），也给技术债埋下了更多的种子。一个企业如果不重视软件测试的话，做出来的软件项目绝对是一个不合格的产品。
代码负债
编码负债
代码不规范，不严谨。会开发团队难以协同工作，良好的，统一的编码规范更好维护以及迭代项目。有些软件工程师为了痛快一时，快速开发产品，无视团队编码规范，导致后期项目迭代的时候，代码杂乱不堪，出了问题也找了老半天，同事也爱莫能助。这就是编码不规范的后果。除此之外，还有编码组织问题，要懂得面向对象编程（OOP）或者是函数式编程（FP），有利于代码的重构，一定程度上减少技术债。
业务负债
经常采用投机取巧方案修补漏洞。没有深度思考自己业务逻辑代码或者是没有彻底理解漏洞产生的原因，通过简单的逻辑判断就修补代码，或者是强制修改数据库的用户数据。这种救得了一时,救不了一世方案不可取，只造成更多的技术债。
架构负债
项目组织不合理，软件耦合度高会导致项目难以维护。正所谓牵一发而动全身，业务需求不断新增，软件项目很难迭代，后来发现代码没法改，不得不推倒重来，重新开发新项目。
管理负债
工期负债
不得不说，项目期限还是问题。现在的项目正如马士兵老师说的那样，现在的项目赶紧做，做完之后赶紧拿钱，说白了就是赚快钱。企业为了抢占市场占有率，必然想短期出产品，因此软件开发工程师必然只能沿用一些老解决方案，加快想项目开发进度。开发出来的产品质量和以前没有太大区别，软件生命周期短。
人员负债
一个人员流动性大的开发团队导致项目开发难以开展或者是开发进度缓慢，再加上团队中的开发人员能力不尽相同，各有各的风格，即使规范了代码风格，但每个人的代码实现思路也不尽相同。技术债也随着人员流动而加大。
成本负债
项目的软硬件环境配置决定项目的成本负债。控制好成本负债才可以获得更多的收益。聪明的人绝不会贪小便宜，只顾眼前的成本利益而造成更大的陈本负债，该花钱的地方就有花，不要节省。
参考资料：
浅谈对技术债的理解
