微信号:imooc-com

介绍:慕课网是一个超酷的互联网、IT技术免费学习平台,创新的网络一站式学习、实践体验;服务及时贴心,内容专业、有趣易学。专注服务互联网工程师快速成为技术高手!

程序员为什么都选择不还清「技术债」?

2018-09-20 07:50 慕课网



技术债是修复代码质量问题所需消耗人力资源估值,可以说人人都有可能会欠下“技术债”。


“我很想改进这种设计,但是我没有时间。”

“我真的很想整理这些,但是这不属于这个任务的范围。”

“我们现在没有时间重新思考这个模块的架构。”


这些话相信每个开发人员都说过。而且每个开发人员也整日把这些话挂在嘴边。


正如我们不愿承认的,其实很多时候这些都是应该要做的事情。


曾经我也很希望提供优雅美观的代码,但是现实情况是,我的老板付钱给我,让我提供对他们和他们的客户有用的功能,即价值。


专心为客户提供价值,是现代科技业务最大的重点,而且随着Eric Reis的“精益创业”的流行,以及其对整个“科技产品开发”思想的启发,这个重点变得更为突出。但是,我们所有人(包括Reis和他的朋友)也都认识到,全心全意提供面向客户的功能是一个错误。


这是导致我们陷入熟悉的“技术债务”的罪魁祸首,接下来就是“技术破产”,最终我们在恐惧中承认失败,所有工作都白费,所有代码必须“完全重写”。




因此,作为软件开发人员我们普遍认为:维护(即保持代码库处于健康状态),是我们工作重要的组成部分。


但是,如果我们都认识到保持健康的代码库,是工作的重要部分,那么为何我们常常发现“价值”,占据了我们100%的工作时间,而投入到“维护”的时间几乎为0呢?


我们知道维护是必须的。我们的技术负责人知道。我们的首席技术官常常说起,有时甚至连CEO都熟悉“技术负债”的概念、以及技术人员对此的恐惧。


然而,在现实中,我们工作的重点依然没有变。“我现在没有时间处理这个问题。”




这个问题有什么正当理由吗?


最常见的解释理由是“产品经理是大坏蛋”的理论:我没法去做技术维护,因为产品经理不断给我分配功能开发。



我发现这个解释不够充分,原因有两个:


首先,产品经理与我们形容的形象相反,他们也是讲道理的人。他们也知道而且很担心技术债务,他们也想避免这种情况。


而且即便他们不想这么做,我们还有技术人员,保持技术方面的健康是技术领导团队的工作。


其次,根据我们以上的观察,维护是你的工作的一部分。


从什么时候开始你的工作需要领导批准?


医生不会因为说“我们承诺在本季末保持客户的健康”,才去做彻底的检查和测试。


一个专业的承包商不会在确认地面足够支撑建筑的结构前,就开始铺设地基。


那么这与软件有何不同?很多原因在于我们这个行业的极端不成熟。


我们没有足够专业的标准,让保持代码健康成为流程中不可或缺的一部分,就像建筑中的安全检查,或医疗服务中的卫生处理。


这反过来又说明,我们没有足够的专业能力,来证明这样的标准,也就是说我们在上一个项目中花了时间来“偿还技术债务”,但却没有成功。那么我们怎么可能要求,在下一个项目中还这么做呢?


当然,对于那些追随Bob Martin叔叔以及其他许多年来一直说同样的话的人来说,这个结果并不新奇。


但是我相信事情还没完,不全是因为我们不够优秀(不够专业)做正确的维护。部分是因为我们不愿尝试。请记住——我这里说的是“我没这么做”,而不是说“我努力了,但是做不到”。






为什么我们不愿尝试维护?


假设你是一个典型的开发人员。某一天,他们可以选择创造价值还是做维护。我知道他们(几乎所有人)都会选择前者。


尽管他们的技术负责人、首席技术官和同事每天都在讨论技术债务的忧患。


但试想想,当你(或同事)因为交付对客户非常有利的功能,而受到称赞的情况有多少次?


再比较一下你(或同事)因为做了代码重构、维护或写技术文档,而受到表扬的情况有多少次?



或者,从另一个角度来看,对于你个人而言,如果你们计划了100个给客户的功能,但是有1个未能交付,那么你认为后果是什么?


比较一下,对于你个人而言,如果有100次机会,可以改进或维护代码库,但是这100次你统统没有做,那么你认为后果是什么?


如果你的工作环境,与我见过的所有工作环境都很相似的话,那么你知道交付优秀的维护工作,可能你的同事会感激你,但是交付功能可以让你赢得升职。


你会选哪个?这个结果一点都不惊讶或新颖;凭我对市场经济仅有的一点了解,我也知道每个人都会努力争取最大化利益。


如果你按照代码行数付钱,那么相同的功能,你拿到的代码量将是10倍之多。如果每改好一个bug,就可以收到一份奖金,那么你的应用程序里面会布满bug,以方便他们日后慢慢改。

如果维护代码没有切实的奖励,那么你就会陷入技术负债。


我们怎样才能将开发人员100%投入到价值的精力转移到0%的维护工作上呢?


简单来说,经理不能只是动动嘴皮子;不要再喋喋不休地讨论,如何解决技术债务。相反,应该表明你愿意付钱找人解决这个问题。




平衡在维护中的重要性


虽然我们不希望开发人员在价值和维护上投入到精力比例为100比0,但也不想变成50比50。


如何将维护相关的工作,作为年度考核中的一部分呢?或者作为开发规范的一部分呢?


在问开发人员“这些功能做得怎么样了?”的时候,每问10次,可否有1次问“最近代码改进怎么样了?”


一旦人们明白,保持代码健康也会受到奖励,包括他们的升职、加薪和公司内的位置等会受其影响,他们就会自己找时间、范围和精力来完成。


不过,为了有效判定某人是否达成了某个目标,你需要能够度量。度量代码的质量,或代码质量改善度,并不是一个可以轻易解决的问题。如何度量这个话题需要开一篇博文、写一本书或学术研究来解释。


本文的描述符合你的经历吗?还有什么合理的原因,导致我们不愿偿还技术债务吗?或者也许这压根不算什么问题?

欢迎大家分享自己的见解~




原文出处:

https://uselessdevblog.wordpress.com/2018/06/24/why-we-all-choose-to-not-pay-back-tech-debt/

译者:弯月,责编:胡巍巍




点击下面的蓝字,查看更多好文


① 这些年轻的程序员是如何实现“开挂”的人生

② 我是怎么把一个项目带崩的

③ 数据可视化发现“吃鸡”秘密



慕课网小程序上线了,快来体验





 
慕课网 更多文章 祭出程序员的大招:34金币时间管理法 我是怎么把一个项目带崩的 “职业程序员”不必那么“职业” 如影随形的设计模式与现实世界 作为50 岁的开发者,面对被裁的命运,我如何绝地求生?
猜您喜欢 阿里ASRC广州站雷峰安全沙龙八卦 【致歉信】尊重版权,从我做起! 极客帮创投蒋涛:CES 第四天(结语篇) 双十一福利来了!送书送教程送邀请码! 赛尔推荐 | 第9期