技术债是什么。
出自于沃德·坎宁安之口，他首次将技术的复杂比作为负债，简称技术负债（技术债）。软件开发本来就是一项很复杂的工程，所以很多人都软件开发当作软件工程看待。开发出来的软件是用来服务于各个领域（金融，医疗，购物等），我们程序员不一定能完全了解某个领域（术业有专攻），所以就没法很好的把控这个领域的软件架构，必然就会产生技术负债。技术债是无法避免的，只是产生技术债或多或少的问题。
技术债是怎么产生的。
我认为技术债大概分为三大类。
文档负债（包括需求分析负债，开发文档负债，测试文档负债）
需求分析负债
不懂需求分析的软件开发工程师不是好的软件开发工程师，遇到问题一定要与上级领导或者客户及时反馈，及时沟通，某些需求不能做就是不能做，要持有一种质疑的心。找正确的途径去反馈问题而不是背地里去发恼骚，要懂得有效的沟通方式，让客户或者是领导理解技术实现痛点。如果软件开发工程师没有理解好项目需求而盲目开发项目，必然导致领域业务与开发业务不匹配， 从而付出更多的时间与精力去开发项目。
开发文档负债
软件开发文档不齐全，或者是软件文档功能与项目代码功能不一致。
有两种以下情况：
（1）项目没有制定开发文档。没有制定代码规范文档，接口文档等相关技术文档。光看代码不看文档就够辛苦了，即使语义化变量名与函数名，也难易快速理解。（少见）
（2）项目没有更新开发文档。项目开发初期还有文档，后来文档没有对应没有更新，因为有些需求几乎都是临时新增的，导致后期项目迭代的时候就造成大量的冗余代码。（常见）
软件开发文档是项目最系统最全面的反映，看文档比看代码更容易理解项目的功能模块。
测试文档负债
体现于软件测试覆盖率低，测试用例不足。
在大多数的企业中，为了控制人力成本，软件测试都是由软件开发工程师去完成，而不是由专业的软件测试人员去负责，这样做往往会忽略了一些软件漏洞（当局者迷，旁观者清），也给技术债埋下了更多的种子。一个企业如果不重视软件测试的话，做出来的软件项目绝对是一个不合格的产品。
代码负债（包括架构负债，编码负债，业务负债）
架构负债
前期项目架构评估不够充分，导致项目组织不合理，软件耦合度高，后期项目难以拓展与维护。
正所谓牵一发而动全身，业务需求不断新增，软件项目很难迭代，稍有不慎就容易出现漏洞，后来发现代码没法改，不得不推倒重来，重新开发项目。
编码负债
编码质量不高，导致开发团队难以协同工作。当遇到软件产品迭代就会出现一堆技术债，软件产品更是漏洞百出，难以维护。
体现在以下几个方面
（1）代码命名规范：代码命名没有规范，存在大量杂乱不堪的命名代码。
（2）代码复杂度：条件语句过多，流程控制过于复杂，代码嵌套过多。（常见回调地狱）
（3）代码耦合度：代码中参数，类，接口高耦合，需要大量修改代码。
（4）代码行数：存在大量未使用的代码。
良好的，统一的编码规范更好维护以及迭代项目，有利于代码的重构，一定程度上减少技术债。
PS：当然每个团队都有自己的标准，以上只是参考指标，并不是唯一指标。
业务负债
经常采用投机取巧方案修补漏洞。没有深度思考自己业务逻辑代码或者是没有彻底理解漏洞产生的原因，通过简单的，过多的条件判断就修补代码漏洞，或者是强制修改数据库的用户数据。这种救得了一时,救不了一世方案不可取，只造成更多的技术债。
管理负债（包括工期负债，人员负债，协同负债，成本负债）
工期负债
项目期限也是技术债产生原因之一。现在的项目正如马士兵老师说的那样，现在的项目赶紧做，做完之后赶紧拿钱，说白了就是赚快钱。企业为了抢占市场占有率，必然想短期出产品，因此软件开发工程师必然只能沿用一些老解决方案，加快想项目开发进度。开发出来的产品质量和以前没有太大区别，软件生命周期短。
人员负债
一个人员流动性大的开发团队导致项目开发难以开展或者是开发进度缓慢，再加上团队中的开发人员能力不尽相同，各有各的风格，即使规范了代码风格，但每个人的代码实现思路也不尽相同。技术债也随着人员流动而加大。协同负债
让开发团队的人知道“我是谁，我在哪，我在干什么”。
有两种以下值得注意：
（1）管理者必定充分认识自己的定位，该做什么就做什么，不要过分干涉组员的工作，但要监督组员工作质量。
（2）管理者必定认真分配组员的开发任务，分工明确，各尽其职，避免重复开发模块。
良好的协同可以避免一些重复工作，减少软件冗余代码，促使项目开发效率会事半功倍，保证如期进行，从而减少技术债增加。
成本负债
项目的软硬件环境配置决定项目的成本负债。控制好成本负债才可以获得更多的收益。聪明的管理者绝不会贪小便宜，只顾眼前的成本利益而造成更大的陈本负债，该花钱的地方就有花，不要节省。
技术债需要还吗？
技术债是躲不掉的，不还技术债付出的代价更高。（出来混，迟早要还的）
还债的好处，避免软件漏洞，提高软件健壮性，能保证一段时间不用加班。
还债的缺点，无法支撑大规模的新项目需求，在原有基础上重构业务逻辑代码有一定的技术风险。
不还债的好处，等待项目推倒重来，重新架构软件模型，提高软件扩展性与稳定性。
不还债的缺点，新项目必然花费的人力成本与时间更多，加班难以避免。
还不还债，自己看着办吧。
总之，一个有经验的优秀的软件工程师，绝对不会轻易背负过多的技术债，即使遇到技术债，不管有多少，都能把这个技术债的坑给填了。这样才会成为名副其实的软件工程师，不会被同行所唾骂，不会被企业所淘汰，赢得同行的尊敬。