开发就像借贷：必须偿还的技术债

下面，我们先来说说什么是技术债？

技术债一词是由「沃德·坎宁安」先生于 1992 年提出，用来形容技术的复杂性及不严谨性。他将第一次发布代码，比作借了一笔借贷。只有通过不断重写代码来偿还债务，小额负债便可以提高开发速度。但久未偿还债务会引发产品崩坏等危险。复用马马虎虎的代码，类似于负债的利息。而整个公司有可能因为松散的实现，不完全的面向对象的设计，或其他诸如此类的负债，而陷入窘境。

通过「沃德·坎宁安」先生的描述，我们能够知道技术债是我们在软件架构或代码编写过程中有意无意地犯下的错误。但随着时间的累积，这种错误会越来越多，就像背负了很多债务一样。然而最让我们头痛的是，无论你拥有多么优秀的团队，你都无法逃脱背负技术债务的命运。哪怕是微软的 offers 团队，面对技术债的产生也是无可奈何的。所以说「技术债是一定会产生的，并且还是是必须要偿还的！」

当我们知道技术债的产生是一种必然结果时，我们再说说它的危害。其实技术债的危害主要是使技术陷入技术债务的恶性循环之中：

当技术团队没有及时偿还技术债务时，技术债会随着时间的推移，不断降低技术团队的开发效率，使得每增加一个功能都困难重重，进而延误业务的进展。这是因为技术债会使得整体代码出现难以处理的问题。为此，开发人员不得不拿出更多的时间来修复这些问题。

而随着业务进展的延误，业务方一定会对技术小伙伴们有强烈的不满与抱怨，这会使得技术小伙伴们产出巨大的压力和挫败感。并使团队陷入无休止的争吵之中，而争吵和指责会让团队成员相互推卸责任，让成员们不敢接受技术升级，并让成员们变得更加保守不愿意偿还技术债务。

这又会进一步加大技术的落后，并使团队的技术水平不断下降。而技术水平的下降，又会进一步影响业务的进展。从而使得整个产品技术进入一个恶性的循环之中，直至产品宣告死亡。

由此可见技术债带来的恶性后果是十分严重的， 所以我们要知道，如何减少技术债的产生。产品技术债的原因，无非一下几点；

产生原因一、开发人员无意中欠下的技术债：

大家可以想想一下，程序员的工作日常。程序员每天不光要写出成百上千行技术代码，还要让这代码能够满足业务需求并有一定的延展性，这就使得技术人员的工作量十分巨大。而如此巨大的工作量下，很难保证代码 100% 正确。因此想要减少开发人员无意中产生的技术债，则需要技术团队拿出固定时间一起核查每个技术人员的代码，也称作 Reveal 代码。

产生原因二、产品设计上欠下的技术债

如果产品的设计上存在很大的局限性，那么即便是技术小伙伴的代码写的再好，也会产生很大的技术债务。这是因为产品的局限设计会使得产品只能满足当前的业务需求，而无法应对之后的产品功能升级。而当产品功能升级时，技术小伙伴只能完全重新编写代码。因此减少这部分技术债的方法是要让产品设计人站在一个更高的角度进行产品设计，产品要满足的不光是当前的业务需要，还要为未来而设计，为将来的产品升级做出一定准备。

产生原因三、开发时间上欠下的技术债

我相信做技术的同学一定经常听到这样的话：「我们的时间很紧，必须尽快上线，我们暂时赶一下进度，后面再重构。」其实作为一名产品人的我，也曾经说过这样的话。我可以告诉大家，当我说出这句话后，我的团队的确按照我的要求，成功缩短了 2 天的开发时间，使得我们的产品能够提前上线。但是我们之后却用了一周的时间，来处理赶工带来的技术债务。所以，在此我奉劝大家不要因为开发时间的缘故去欠下技术债，因为当你还债的时候，所需的时间可能是之前的很多倍。

产生原因四、管理上欠下的技术债

我们知道，技术开发是要多人合作进行工作地。但是由于每个开发人员的逻辑思维和编写习惯有所不同，因此想要代码拥有统一性，就需要所有的开发人员按照技术规范标准进行代码的编写与命名。而规范的执行，一定需要人员的监管。如同法律需要警察来维护一样，当只有法律没有警察时，法律只是一个摆设。技术开发也是如此，当管理不够严格时，大家很难遵守开发标准，为此就会产生技术债。而减少管理上欠下技术债的方式就是加强技术管理，不断 Reveal 代码。

产生原因五、战略上欠下的技术债

在之前的课程中我给大家讲解过，产品是战略的表达。所有战略的错误会导致产品功能上的错误，进而影响代码的正确性。因此，战略的错误也会产生技术债务。而减少战略性技术债的方法是使用可用性测试，通过可用性测试判断战略的正确性。

最后，我再次强调，技术债是一定会产生的，但是我们要积极的应对技术债，尽量拿出时间去消除技术债，提高我们产品的使用体验，降低我们产品的死亡风险。