欠债还钱，天经地义： 开发团队如何还技术债？

Posted 2022-02-06 朱清云的技术博客

年底了，兄弟们项目交付的压力没有那么大了，因此每天有时间大家一起来过过项目的代码[平常也应该过代码的，而不是项目交付后再过代码]总结出来了很多问题和技术债：

1. 魔数
2. for循环层次嵌套太多
3. 公共类重复开发
4. 公共逻辑重复开发
5. 缺乏单元测试
6. 方法里面实现逻辑的代码行数太长
7. 设计模式用的少
   。。。。。。

代码写好就交，意味着欠债的开始；稍微欠点儿技术债的确可以加快开发速度，但是前提是要及时重构代码；如果一直不还，后果很危险，因为有的债是高利债，拖的时间越久，要还的债越多，甚至最后造成项目和产品的破产，重新开始立项；
下面是精益的鼻祖戴明博士的观点：

如果关注质量，那么长期来看质量会提升，成本会降低；

如果关注成本，那么长期来看，成本会提升，质量会降低！

曾记何时，听到产品团队抱怨，一个小小的改动，去年1天就改好交给客户了，今年类似的功能，开发团队竟然说要4~5天，这简直不可思议，导致产品和开发之间的隔阂和误解越来越深；

经过深层次思考后，个人觉得根本原因之一还是因为软件项目的技术债没有及时还：技术债不仅仅包括代码的bug，代码的风格，代码的安全性，可读性；其实还包括从设计角度留下的债，由于赶项目交付，本应该坚持的“开闭原则”（修改封闭，扩展开放），或者应该灵活处理的却hard code了，本应该抽取成公共方法或者服务的，却四处遍地开花 等等不一而足；江湖混，欠下的债迟早是要还的！下图的阴影部分就是欠的技术债。随着系统的功能越来越多，代码越来越复杂，如果不能高效的组织代码结构和代码本身，就会印证那句话“剪不断，理还乱，别有一番滋味在心头，夜不能寐，日食无味，天天想着快速交付变更，结果如踩泥地，越陷越深！”

技术债越多，变更的成本越大，请君看下面的曲线：技术债和成本的几何曲线。欠的技术债越多，随着时间的推移，其所花费的变更成本越大！

而技术债找出来后，应该如何去还技术债呢？借用敏捷项目管理思维方式来看，应该首先做下面的三件事情把技术债管理起来：

1. 从现在开始，不要继续欠债

以始为终，不忘初心！ 既然已经了解了技术债的不好，那就从现在开始，从现有的手上项目开始，尽量不要旧债未还，又添新债。可以通过代码走读，
自己走读，发现问题，立马解决问题，不要再拖到后面。对于核心算法，该用TDD就用TDD，改写单元测试就写单元测试；
同时对完成任务的定义的要求也要严格起来；代码走读发现的重大问题不整改，就不让合并代码到发布分支！

2. 了解所以你欠下的技术债并记录下来

通过代码开发的插件，比如FindBugs，阿里代码规范插件，SonarQube，设计评审，QA测试等方式把发现的技术债记录下来。

3. 逐步偿还技术债

偿还技术债，笔者不建议抽取特定的一个时间段大家一起来重构代码，偿还技术债（当然如果这段时间的确没有新的项目或者功能需要做，倒也可以尝试，但不建议）；在偿还技术债的时候，笔者建议，把技术债分轻重缓急，各个逐渐击破解决！

[1] 并非所有的技术债都应该还
如果你的软件产品马上就要被替换下线了，或者只是一个一次性原型（但是如果此原型要继续进行迭代，则还是要还的），又或者只是暂时的解决方案（一个月后马上就下线了）等等，对于此类的坏资产，即使去还技术债，意义也不大。

[2] 优先还高息技术债
对于经常被使用的，被依赖的公共模块或服务；或者用户使用最为活跃的功能；这一块的技术债是最值得优先偿还的。因为其带来的收益也是立竿见影的，也是巨大的。

[3] 应用童子军原则，有债就还
每次开发团队在开发新的产品或者功能的时候，从现在开始就要尝试把产品设计和实现做的更好，而不更差；对于在开发过程中偶然发现别的模块的问题或者Bug的时候，我们也可以根据我们实际的安排去修改或者重构这部分代码；比如可以把你发现的问题，创建一个JIRA Task，在下个Sprint甚至如果紧急且重要的话还可以临时加到这个Sprint去重构；

[4] 分期偿还技术债
就和现实生活中，我们分期还房贷一样，对于前期欠下的债；我们在前期整理出来的可视化的技术债，我们根据重要程度和影响范围分期，分步偿在每个Sprint里面加一些偿还技术债的任务。

[5] 一边做对客户有价值的新功能，一边偿还技术债

希望上面的笔记总结，能够抛砖引玉！