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

发布于:2020 年 6 月 24 日 19:12

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

作为一名技术人,你常常会听到这样的话:

“先快速上线”

“没时间改”

“再缓一缓吧”

“以后再解决”

“先用临时方案处理”

……

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

作为一个程序员,我们反对复制粘贴,但是我们经常会见到相似的代码,相同的二方包,甚至整个代码库复制,似而不同的应用比比皆是。

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

图片来源:

https://www.monkeyuser.com/

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

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

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

一、技术债是什么?

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

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

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

我们经常会把代码称之为宝贵的资产,因为技术债在代码层面的普遍存在,所以我们也可以说,代码就是债务。只要你是程序员,可以说你的一生都会被技术债所影响。

所以,技术债本身是对项目或者代码质量的重要衡量指标。

二、 技术债的恶性循环

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

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

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

再之后,团队开始无休无止的争论, 新人想要改革,老人害怕风险,每个人固守自己的业务不敢接受升级,N 变更带来的 N*N 的风险,没人愿意承担。

在这之后,长期技术不升级导致技术落后 ,这个团队的技术竞争力下降,每个人都能感受到团队无论是技术能力还是商业价值都在下降,进而导致更大的挫败感。

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

三、技术债是如何产生的?

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

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

“我们暂时赶一下进度,后面再重构。” 如果能够经过合理分析,为了短时间赶工做出一定的牺牲,后面再有计划地重构升级,技术债本身并不一定是全是坏事。但是很多时候这句话成了空头支票,最后,就是变成了上一种恶性循环。

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

四、如何解决技术债

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

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

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

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

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

2、同时因为很多“复制 - 粘贴式”代码是跨代码库的,所以评估工具也只能参考,最好能够多仓库横向对比。

解决技术债的方案

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

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

可以参考技术债产生的原因,所有的因素都是想法的偏差,只要调整正确的态度,技术债就是可以规避的。

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

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

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

后记

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

本文引用:

[1] https://www.monkeyuser.com

[2] https://www.jarchitect.com

[3] https://daedtech.com/5-things-ive-learned-in-20-years-of-programming

阅读数:123 发布于:2020 年 6 月 24 日 19:12

更多 文化 & 方法、最佳实践、方法论 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 大咖对话 | 陶真:技术人要爱上问问题,而不是自己的解决方案

    要爱上问题,而不是爱上我们的解决方案。学会从客户痛点的角度出发,而不是从解决方案的角度出发。

    2019 年 4 月 5 日

  • 如何在遗留代码基础上开发

    对于大多数开发者来说,在遗留代码基础上开发是日常工作的一部分,毕竟从头开始创建全新系统的机会不是很多。架构师、《漫谈设计模式》作者刘济华结合自身的实际经历分享了如何在遗留代码基础上开发的经验。

    2013 年 3 月 19 日

  • 饿了么 4 年 + 阿里 2 年:研发路上的一些总结与思考

    本文基于在饿了么4年和阿里巴巴 2 年研发经历,从技术、业务、管理和架构层面分享作者的一些思考。

    2020 年 7 月 27 日

  • 敏捷与盲目自信

    盲目自信常常源于一厢情愿的想法。​它是一个状态,这个状态表现为,预期与现实可能相差很大,然而在一个特定的时间段内它却又给人一种一切尽在掌控之中的感觉。​敏捷开发中有很多这样的情况,这导致一个团队​即使在每况愈下时,也要坚持那些盲目的自信​。

    2011 年 4 月 20 日

  • 技术债还是有用的隐喻吗?

    在LinkedIn敏捷联盟小组上引发了一场对“技术债”在当今全球化软件开发世界中是否还是有效的隐喻的质疑。这个讨论表明即使在20年之后这个隐喻的成效仍被强烈支持。

    2011 年 8 月 7 日

  • 该不该去创业公司?

    当你面临加入创业公司的选择时,问问你的期望,评估现实的条件,再做出满意的选择;决策过后,可能有遗憾,但没不甘。

    2018 年 11 月 19 日

  • 加班:加班逃不过,如何用正确姿势加班?

    不浪费时间的好方法,就是做一些没有业务压力,但是可以提升自己的事情。

    2020 年 7 月 22 日

  • 从软件工程的角度解读任正非的新年公开信

    这些年软件工程被提起的其实不多,大家关注的更多是各种新酷的技术,而对于这种软件开发最基础的理论视而不见。

    2019 年 1 月 5 日

  • 质量与速度的均衡:让“唯快不破”快得更持久

    在恰当的时间“举债前行”,而在平时的开发工作中要持续定位技术债任务,并解决高优先级的部分,才能让开发快的持久。

    2019 年 9 月 23 日

  • 世界上没有技术驱动型公司?

    科技公司到底是为技术驱动还是业务驱动的争论古来有之。对于技术人员而言,拥有良好工程师文化、代码文化,核心竞争力是技术、尊重技术、技术人的公司似乎就可以称得上是技术驱动型公司。但事实果真如此吗?本文作者给出了不一样的看法,他认为,世界上没有技术驱动型公司,谷歌、脸书不是,阿里、腾讯也不是。

    2019 年 10 月 11 日