浅谈对技术债的理解

Posted 2020-11-21 sroot

技术债是什么。

 

出自于沃德·坎宁安之口，他首次将技术的复杂比作为负债，简称技术负债（技术债）。软件开发本来就是一项很复杂的工程，所以很多人都软件开发当作软件工程看待。开发出来的软件是用来服务于各个领域（金融，医疗，购物等），我们程序员不一定能完全了解某个领域（术业有专攻），所以就没法很好的把控这个领域的软件架构，必然就会产生技术负债。技术债是无法避免的，只是产生技术债或多或少的问题。

 

技术债是怎么产生的。

 

我认为技术债大概分为三大类。

 

文档负债（包括需求分析负债，开发文档负债，测试文档负债）

 

需求分析负债

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

 

开发文档负债

软件开发文档不齐全，或者是软件文档功能与项目代码功能不一致。

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

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

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

 

测试文档负债

体现于软件测试覆盖率低，测试用例不足。

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

 

代码负债（包括编码负债，业务负债，架构负债）

 

编码负债

代码不规范，不严谨。会开发团队难以协同工作，良好的，统一的编码规范更好维护以及迭代项目。有些软件工程师为了痛快一时，快速开发产品，无视团队编码规范，导致后期项目迭代的时候，代码杂乱不堪，出了问题也找了老半天，同事也爱莫能助。这就是编码不规范的后果。除此之外，还有编码组织问题，要懂得面向对象编程（OOP）或者是函数式编程（FP），有利于代码的重构，一定程度上减少技术债。

 

业务负债

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

 

架构负债

项目组织不合理，软件耦合度高会导致项目难以维护。正所谓牵一发而动全身，业务需求不断新增，软件项目很难迭代，后来发现代码没法改，不得不推倒重来，重新开发新项目。

 

 

管理负债（包括工期负债，人员负债，成本负债）

 

工期负债

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

 

人员负债

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

 

成本负债

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

 

技术债需要还吗？

技术债是躲不掉的，不还技术债付出的代价更高。（出来混，迟早要还的）

还债的好处，避免软件漏洞，提高软件健壮性，能保证一段时间不用加班。

还债的缺点，无法支撑大规模的新项目需求，在原有基础上重构业务逻辑代码有一定的技术风险。

 

不还债的好处，等待项目推倒重来，重新架构软件模型，提高软件扩展性与稳定性。

不还债的缺点，新项目必然花费的人力成本与时间更多，加班难以避免。

还不还债，自己看着办吧。

 

总之，一个有经验的优秀的软件工程师，绝对不会轻易背负过多的技术债，即使遇到技术债，不管有多少，都能把这个技术债的坑给填了。这样才会成为名副其实的软件工程师，不会被同行所唾骂，不会被企业所淘汰，赢得同行的尊敬。