还债啦！快来看看技术债产生的原因和误区

在之前的技术债系列文章中，作者详细介绍了技术债的概念，技术债的分类，技术债在日常开发中经常出现的场景。通过这些场景，可以让大家举一反三，有效避坑。下面的章节，会给大家详细讲解技术债产生的原因，及其几个对技术债的误区。

一 技术债产生的原因

我们把技术债分为了三种：

不可避免的技术债：它们是不管采取什么预防措施，都会积累；

低级技术债：它们是团队成员，组织以及过程不成熟所造成的；

策略性技术债：则是在债务累计收益大大超过债务成本时可能选择承担的债务；

        这里，我们不讨论不可避免的技术债。然而，低级技术债和策略性技术债都是迫于业务压力而必须满足某个迫在眉睫的重大最后期限而造成的，也就是如期完工的压力所致，如图一所示。纵轴为我们想要在预计发布日期完成的工作量，横轴为所需时间。工作量和预期发布日期之间的连线代表匀速瞄准预期发布日期必须达到的预计速率。我们希望按照预计速率开展工作完成高质量特性，同时，还希望尽量减少技术债。可是，开工后，我们发现，为了产出高质量结果，实际的工作速率远远低于预计速率。如果继续按照实际速率进行，将会错过理想的发布日期，而是在可能发布的日期完成。此时此刻，我们需要做出一个决策：是缩减范围以满足理想的发布日期，还是希望增加更多时间等到可能发布日期发布？很不幸的是，在实际工作中，产品负责人往往都会否决这两种方案，而是强令团队必须在理想的发布日期交付所有特性，于是，我们试图以错误的方式提高速率。这种走捷径才能满足快速工作以满足理想的发布日期的做法，就会产生大量的技术债。这些技术债的来源五花八门，或许是设计差强人意，或者是代码不完整，或者是某些特性类型的测试被推迟等等，如图二所示。

图一

图二

二 关于技术债的几个误区

        误区一：只要代码足够完美，就可以避免技术债。很多人都认为技术债是写代码的人一手造成的。只要代码写的足够完美，考虑的足够全面，就可以避免技术债，这个是错误的。上篇我们也分析了技术债产生的众多场景，有很多不是代码人员可以掌控的，有的可能是产品提的需求文档的不完善，也有可能是某些第三方系统所引起的，让人防不胜防。

        误区二：减少测试可以提高速率。很多人认为测试属于额外开销，只要减少测试，就可以提高速率，这也是错误的。实际是减少测试既会增加债务又会减缓速率。因为问题潜伏很深，越晚发现，修复所花时间就越长，所产生的技术债就越大。例如：我们之前在进行一个列表功能开发的时候，用了一个列表组件，技术人员为了快速上线，只做了功能方面的测试，忽略了性能测试，等系统上线后，一个月内都没有发现问题。一个月后，广告的开发团队在列表中接着增加了广告位和三级列表筛选。广告位很快就卖出，广告功能着急上线，突然做性能测试的时候发现之前用的列表组件有性能问题，三级筛选功能的增加，导致列表记录数大增，会导致大量的OOM的问题，列表必须重构，否则系统无法上线。后来实在没有办法，只能跟客户协商，阉割三级筛选功能的同时，快速替换列表组件，列表页面和广告功能都需要重新开发，造成了非常不好的影响。

        误区三：所有的技术债都必须尽快偿还。其实并不是所有的技术债都应当偿还。有些情况下的技术债是可以不用偿还的，现总结为以下三种：

        1）行将就木的产品，技术债可以不用偿还。如果产品已经累计大量技术债且已经临近生命周期的终点，再投入大量精力偿还技术债就是财务不尽责了。如果产品的价值不高，就不要偿还技术债了，可以让产品退市，把资源投入性价比更高的产品当中去；

        2）一次性原型，不用偿还技术债。有时我们为了获得知识或者验证某个结论而创建的一次性原型，它不是为了市场而设计的，所以可能会欠下一些技术债。由于它们是一次性的，所以也没有必要偿还其中的技术债；

        3）短命的产品，由于经济因素可能支持不偿还技术债。组织通常不会开发预期只有三个月生命力的产品，我们更愿意开发能够长销的产品。所以，那些短命的产品，哪怕是多花一个子儿去清理系统，都将会是罪过；

我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表