@程序员 你的技术债务还清了吗?

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

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

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

这些话把每个开发人员的耳朵,都磨出茧自来了。更不像话的是,每个开发人员也整日把这些话挂在嘴边。

更让人心有不甘的得失,很多时候这些都是应该做的事情。

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

专心为客户提供价值,是现代科技业务最大的重点,而且随着Eric Reis的“精益创业”的流行,以及其对整个“科技产品开发”思想的启发,这个重点变得更为突出。

但是,我们所有人(包括Reis和他的朋友)也都认识到,全心全意提供面向客户的功能是一个错误;这是导致我们陷入熟悉的“技术债务”的罪魁祸首,接下来就是“技术破产”,最终我们在恐惧中承认失败,所有工作都白费,所有代码必须“完全重写”。

更多精彩内容欢迎关注可以中国公众号:oschina2013

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

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

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

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

维护的正当理由

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

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

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

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

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

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

更多精彩内容欢迎关注可以中国公众号:oschina2013

从什么时候开始你的工作需要领导批准?医生不会因为说“我们承诺在本季末保持客户的健康”,才去做彻底的检查和测试。

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

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

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

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

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

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

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

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

尽管他们的技术负责人、首席技术官和同事每天都在讨论技术债务的忧患。这是为什么呢?你(或同事)因为交付对客户非常有利的功能,而受到称赞的情况有多少次?

更多精彩内容欢迎关注可以中国公众号:oschina2013

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

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

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

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

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

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

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

我们怎样才能将开发人员100%投入到价值的精力转移到0%的维护工作上呢?简单来说,经理不能只是动动嘴皮子;不要再喋喋不休地讨论,如何解决技术债务。相反,应该表明你愿意付钱找人解决这个问题。

平衡在维护中的重要性

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

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

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

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

不过,为了有效判定某人是否达成了某个目标,你需要能够度量。度量代码的质量,或代码质量改善度,并不是一个可以轻易解决的问题。如何度量这个话题需要开一篇博文、写一本书或学术研究来解释。(更多精彩内容欢迎关注可以中国公众号:oschina2013)

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

原文链接:

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

作者:Jhonny,译者:CSDN-弯月

(更多精彩内容欢迎关注可以中国公众号:oschina2013)

你可能感兴趣的:(@程序员 你的技术债务还清了吗?)