入职阿里5年，他如何破解“技术债”？

简介： 做者 | 都铎

做为一名技术人，你经常会听到这样的话：

“先快速上线”
“没时间改”
“再缓一缓吧”
“之后再解决”
“先用临时方案处理”
……

当你埋下的坑愈来愈多，不知道哪天哪位同窗就会踩上一颗雷。特别赞同“人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。”

做为一个程序员，咱们反对复制粘贴，可是咱们常常会见到类似的代码，相同的二方包，甚至整个代码库复制，似而不一样的应用比比皆是。

图片来源：
https://www.monkeyuser.com/

当新人加入团队，老人总要顶着新人鄙夷的目光解释：当初是什么缘由，才致使系统设计得如此丑陋。一边是产品经理忽然心血来潮的需求变更让人暴跳如雷，一边遗留代码和遗留系统让人望而生畏，直到有一天整个崩溃，也不知道锅落谁家。

渐渐地，咱们学会了用技术债当借口。“以前欠了太多债，因此开发慢”、“历史遗留问题，我也没办法”，后来，咱们失去了热爱开发的灵魂，只剩下痛苦而缓慢的完成业务的躯壳。

这些背后都是技术债带来的问题。然而，做为程序员的咱们，当咱们听到《没有理想的人不伤心》中“我不要在失败孤独中死去”，咱们仍是会热血沸腾，还会想要迎难而上，因此，今天就让咱们搞懂技术债，进而搞定技术债。

1、技术债是什么?

“技术债”是1992年被沃德·坎宁安提出来。在金融领域经过短时间的借贷得到充足的资金加快发展，代价就是除了本金以外还要付出利息。软件领域也是同样，为了尽快上线，暂时不顾代码质量，从而欠下技术债。然后续的开发持续下降开发效率，就像还利息同样。

经济债务相对容易衡量，只须要计算归还多少本金和利息。而技术债更像不规范的高利贷，不只不容易衡量，并且很容易陷入无限还债的深渊。

咱们常常会把代码称之为宝贵的资产，由于技术债在代码层面的广泛存在，因此咱们也能够说，代码就是债务。只要你是程序员，能够说你的一辈子都会被技术债所影响。

因此，技术债自己是对项目或者代码质量的重要衡量指标。

2、 技术债的恶性循环

首先，技术债确定会不断地下降开发效率，每加一个功能都困难重重，进而拖慢业务进度。

以后，业务上的挫败感会给程序员自身带来更大的挫败感。就像天天被人上门讨债的负债者，当杨白劳的滋味相信没人喜欢。

再以后，团队开始无休无止的争论，新人想要改革，老人惧怕风险，每一个人固守本身的业务不敢接受升级，N变动带来的N*N的风险，没人愿意承担。

在这以后，长期技术不升级致使技术落后，这个团队的技术竞争力降低，每一个人都能感觉到团队不管是技术能力仍是商业价值都在降低，进而致使更大的挫败感。

最终，上面这些问题仍是会反过来影响业务，影响商业价值，让整个团队陷入恶性循环之中，最怕人才流失，又让新人更难融入。当团队(公司)业务(商业)价值降到最低的时候，也就是宣告解散(破产)的时候。

3、技术债是如何产生的？

“复制-粘贴式开发模式。” 技术债的认为感知是有延迟的，就像你在高速上超速开车，直到一周后你收到罚单，才知道本身要付出代价。不少团队不顾后果的复制粘贴，直到体会到业务发展缓慢，可是已经来不及了。

“咱们必须立刻上线。” 技术界流传最广的三大借口：“咱们的领域很是复杂，因此咱们有很陡峭的学习曲线”、“咱们的状况特殊，因此没办法写单元测试”、“咱们时间紧急，必须尽快上线”。首先这些假设历来没被证实过，其次假设“咱们时间紧迫，因此必须牺牲质量”成立，可是不表明着“牺牲质量就能赶时间”。最后，在一个必须立刻上线的论调充斥的团队中，那些想要作更多重构和更优设计的人会有深深地负罪感，陷入不断创造技术债的怪圈。

“咱们暂时赶一下进度，后面再重构。” 若是可以通过合理分析，为了短期赶工作出必定的牺牲，后面再有计划地重构升级，技术债自己并不必定是全是坏事。可是不少时候这句话成了空头支票，最后，就是变成了上一种恶性循环。

“解决问题的最好办法是写代码。” 咱们最喜欢的一句话就是“用代码改变世界”。可是偏偏相反的是，若是可以不写代码就能解决问题，才是最好办法。咱们喜欢崇拜代码量，可是无休止的复制黏贴带来的大量代码不但没有价值，反而带来更大的成本。

4、如何解决技术债

让技术债可衡量是解决技术债的第一步

根据观察者效应，将问题暴露出来自己就是一种解决问题的办法。人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。

一、Jarchitect是一款根据必定的规则，评估代码技术债的工具。能够在平时开发中，不断的观察技术债的变化。

图片来源：https://www.jarchitect.com/

二、同时由于不少“复制-粘贴式”代码是跨代码库的，因此评估工具也只能参考，最好可以多仓库横向对比。

解决技术债的方案

直接宣布破产（整个重写）：下线老的系统，用新的系统替代，不少团队都这么干过。尤为当你接手了一个很老的遗留系统，维护成本高，新特性需求积压严重，用新的系统替代多是更好的办法
向后兼容的不断迁移：新作一个系统兼容老的功能，或者直接在老的系统中直接加入新的流程，在测试用例的保证下，将功能随着业务升级一点一点的迁移，慢慢放弃老的系统，删掉代码，最后完成整个升级，将技术债像手术同样切除掉。

最后，请不要再引入技术债

能够参考技术债产生的缘由，全部的因素都是想法的误差，只要调整正确的态度，技术债就是能够规避的。

5、我在阿里五年的技术债解决经历

回想我加入阿里的五年时间，第一个系统就是在作这个系统重写的迁移，老的系统已经严重致使业务发展迟缓，这时候用到的就是“破产清算”，系统重写的方式。

后面作另外一个系统，随着产品的增多，应用不断增长，最后咱们用一个应用承接了全部业务，将老的应用所有下线，作了整个向后兼容的迁移。

后记

最近读了一篇文章《二十年的编程，教会个人五件事》，发现做者做为一个咨询师的角度在几年的时间内写了不少关于软件项目的文章，其中几篇技术债的文章以个人英语读起来很困难，因此为了搞懂技术债，决定边翻译边学习。

本文引用：
[1]https://www.monkeyuser.com
[2]https://www.jarchitect.com
[3]https://daedtech.com/5-things-ive-learned-in-20-years-of-programming