质量与规范，敬我们那些年欠下的技术债

需求分析负债 不懂需求分析的软件开发工程师不是好的软件开发工程师，遇到问题一定要与上级领导或者客户及时反馈，及时 沟通，某些需求不能做就是不能做，要持有一种质疑的心。找正确的途径去反馈问题而不是背地里去发恼骚，要 懂得有效的沟通方式，让客户或者是领导理解技术实现痛点。如果软件开发工程师没有理解好项目需求而盲目开 发项目，必然导致领域业务与开发业务不匹配， 从而付出更多的时间与精力去开发项目

开发文档负债

（1）项目没有制定开发文档。没有制定代码规范文档，接口文档等相关技术文档。光看代码不看文档就够辛苦了，即使语义化变量 名与函数名，也难易快速理解。（少见）

（2）项目没有更新开发文档。项目开发初期还有文档，后来文档没有对应没有更新，因为有些需求几乎都是临时新增的，导致后期 项目迭代的时候就造成大量的冗余代码。（常见）

软件开发文档是项目最系统最全面的反映，看文档比看代码更容易理解项目的功能模块。

测试文档负债 体现于软件测试覆盖率低，测试用例不足。 在大多数的企业中，为了控制人力成本，软件测试都是由软件开发工程师去完成，而不是由专业的软件 测试人员去负责，这样做往往会忽略了一些软件漏洞（当局者迷，旁观者清），也给技术债埋下了更多 的种子。一个企业如果不重视软件测试的话，做出来的软件项目绝对是一个不合格的产品。

文档负债 背景技介术债绍 架构负债 前期项目架构评估不够充分，导致项目组织不合理，软件耦合度高，后期项目难以拓展与维护。 正所谓牵一发而动全身，业务需求不断新增，软件项目很难迭代，稍有不慎就容易出现漏洞，后来发现 代码没法改，不得不推倒重来，重新开发项目。

编码负债 编码质量不高，导致开发团队难以协同工作。

当遇到软件产品迭代就会出现一堆技术债，软件产品更是漏洞百出， 难以维护。

体现在以下几个方面 ：

（1）代码命名规范：代码命名没有规范，存在大量杂乱不堪的命名代码。

（2）代码复杂度：条件语句过多，流程控制过于复杂，代码嵌套过多。（常见回调地狱）

（3）代码耦合度：代码中参数，类，接口高耦合，需要大量修改代码。

（4）代码行数：存在大量未使用的代码。 良好的，统一的编码规范更好维护以及迭代项目，有利于代码的重构，一定程度上减少技术债。

业务负债 经常采用投机取巧方案修补漏洞。

没有深度思考自己业务逻辑代码或者是没有彻底理解漏洞产生的原因， 通过简单的，过多的条件判断就修补代码漏洞，或者是强制修改数据库的用户数据。这种救得了一时,救 不了一世方案不可取，只造成更多的技术债。

代码负债 背景技介术债绍 工期负债 项目期限也是技术债产生原因之一。

现在的项目正如马士兵老师说的那样，现在的项目赶紧做，做完之后赶紧拿 钱，说白了就是赚快钱。企业为了抢占市场占有率，必然想短期出产品，因此软件开发工程师必然只能沿用一些 管理负债 老解决方案，加快想项目开发进度。开发出来的产品质量和以前没有太大区别，软件生命周期短。

人员负债 一个人员流动性大的开发团队导致项目开发难以开展或者是开发进度缓慢，再加上团队中的开发人员能 力不尽相同，各有各的风格，即使规范了代码风格，但每个人的代码实现思路也不尽相同。技术债也随 着人员流动而加大。

协同负债 有两种以下值得注意：

（1）管理者必定充分认识自己的定位，该做什么就做什么，不要过分干涉组员的工作，但要监督组员工作质量。

（2）管理者必定认真分配组员的开发任务，分工明确，各尽其职，避免重复开发模块。

成本负债 项目的软硬件环境配置决定项目的成本负债。控制好成本负债才可以获得更多的收益。聪明的管理者绝 不会贪小便宜，只顾眼前的成本利益而造成更大的陈本负债，该花钱的地方就有花，不要节省。