我写了 500 行代码,老板却给写 2500 行代码的人升职加薪?

zhangyufan 2019-04-10

【CSDN 编者按】有两个程序员分别设计同一个系统:一个用了500行代码实现,一个用了2500行代码设计了一个很复杂的系统。结果竟然是……

我写了 500 行代码,老板却给写 2500 行代码的人升职加薪?

作者 | Neil W. Rickert

译者 | 弯月

责编 | 屠敏

出品 | CSDN(ID:CSDNnews)

以下为译文:

很久很久以前,“自动会计应用协会”(后面简称“自会”)和“综合计算机资本公司”(后面简称“综计”)两家公司素不相识,却在同一时间里认为他们需要一个程序来执行同一项服务。

自会聘请了程序员兼分析师Alan来帮他们解决问题。

与此同时,综计决定聘请一位入门级程序员Charles来解决这个问题,看看他的水平是否真的像他吹嘘的那样。

Alan经历过难度很高的编程项目,他决定使用PQR结构化的设计方法。为此,他要求部门经理再指派三名程序员组成开发团队。于是,这个新成立的团队开始了紧张的工作,着手查看初步报告和问题分析。

反观综计,Charles花了很长时间反复思考这个问题。他的同事发现,Charles经常翘着腿悠闲地喝咖啡。偶尔有人看到他坐在电脑前,但是同一个办公室的同事说,从Charles按键的频率推测实际上他在玩太空入侵者。

时间一天天过去,自会的团队已经开始编写代码了。这些程序员们花了一半的时间写代码和编译代码,还有一半的时间里他们开会讨论各个模块之间的接口。

同一个办公室的同事发现Charles终于不玩太空入侵者了。现在,他除了悠闲地喝咖啡,就是在纸上涂涂改改。虽然他的涂鸦不是玩五子棋,但似乎也没有多大意义。

两个月过去了。自会团队终于发布了开发时间表。再过两个月,他们就可以完成测试版的程序。之后,再经过两个月的测试和加强,就可以交付一个完整的程序了。

经理终于对终日无所事事的Charles忍无可忍,他决定当面质问他。但是,当他走进Charles的办公室时,却意外地发现Charles正在忙着写代码。于是,他决定迟些再质问他,然后打了个招呼就匆忙离开了。从那以后,经理开始密切关注Charles,他打算一旦找到机会,就当面质问Charles。然而,他却迟迟没有找到机会,相反他发现Charles一直都很忙碌。他甚至看到Charles有时忙得连吃午饭的时间都没有,每周还有2-3天在加班。

第三个月结束的时候,Charles宣布他做完了这个项目。他提交了一个只有500行代码的程序。看起来这个程序写得很清晰,而且经过了良好的测试,符合规范中的所有要求。此外,这个程序还有一些额外的功能,大幅提高了该程序的实用性。在测试的时候,除了一个小纰漏(很快就改好了)之外,整个程序表现良好。

与此同时,自会团队已经完成了他们的程序所需的四个主要模块中的两个。这些模块现在正在进行测试,而其他模块已完成。

又过了三个星期,Alan宣布初步版本已提前一周准备就绪。他提出了希望修改的缺陷列表。这个程序还在测试中。除了Alan提出的列表外,用户还发现了很多Bug和缺陷。Alan解释说,这属于正常现象,毕竟这只是初步版本,肯定会有很多Bug。

又过了两个月,自会团队完成该程序的生产版本,大约包含2500行代码。经过测试,该程序似乎满足大多数的原始规格,却忽略了一两个特征,而且对于输入数据的格式也非常挑剔。但是,自会决定安装该程序。他们可以训练数据输入人员,按照要求的格式严格地输入数据。最后,这个程序移交给了一些维护人员,由他们负责缺少的功能。

续集

起初经理对Charles刮目相看。但是,当阅读了源代码后,他发现这个项目实际上比他原本想象的简单许多。现在看起来,即使对于新手程序员来说,这也算不上很大的挑战。

Charles每天大约可以写5行代码,这可能略高于平均水平。但是,考虑到程序的简单性,这也不足为奇。此外,经理还记得Charles游手好闲了两个月呢。

在业绩评审中,公司给Charles涨了工资。一半原因大概是因为通货膨胀。但是,Charles没能得到晋升。大约一年以后,Charles有些失望,于是他离开了综计。

在自会,由于如期完成了项目,Alan受到了大力褒奖。他的主管检查了他做的程序,他大概浏览了一下,发现公司有关结构化编程的标准都实现了。然而,很快他就放弃了阅读该程序的源代码,因为太难懂了。所以,他觉得这个项目实际上比他原本设想的更为复杂。然后,他再次向Alan表示了祝贺。

这个团队中的每个程序员每天可以写3行代码。这与平均值很接近,但考虑到问题的复杂性,所以可以认为他们表现优异。为了奖励他的成就,Alan获得了高额加薪,并晋升为系统分析师。

Tim Mensch的评论

曾经我也是一名年轻聪明的程序员,这个故事引起了我强烈的共鸣。即使在职业生涯的早期,我也可以完成很多高级开发人员所面临的挑战。在我的第一份工作中(作为一名游戏开发人员),我花了几天时间写完了代码,我的经理说我写得比那些经验丰富的开发人员花几个月写的都好。在我的第二份工作中,我优化了一个由有10年经验的高级开发人员编写的工具,经过我的优化,原来需要几分钟的任务只需要不到1秒就完成了。在我的整个职业生涯中,这样的例子层出不穷。

多年以来的开发和学习,让我意识到经验确实很重要。但基本的技术力也同样重要。事实上,上面这则寓言故事说明,基本的技术力比经验更重要,我认为当代开发人员没有认清这个事实。

话虽如此,偶尔我也会犯与Alan同样的错误,创建一个复杂得毫无必要的系统。我能想到并且能够实现一个复杂的解决方案,并不一定意味着它就是最好的解决方案,我需要不断提醒自己这一事实。

所以,我一直在努力做出妥协,有时甚至质疑我自己的解决方案,强迫自己寻找改进的方式,或简化的方法。有时,有人会觉得我花了太多时间来思考某个问题,为何不直接用显而易见的方式来解决,其实我是希望找到一种更简洁的方式来解决问题。花在思考上的时间让人感觉没有在“工作”,但是我可以通过思考找到更好的方式——用更少的代码,实现更强大的功能,且具备可扩展性,还便于阅读。

这就是为什么我觉得上述寓言故事如此重要。经验很重要,但设计和实现方面的技术力可以胜过经验,如果你同时具备经验和技术力,那么就可以出色地完成工作。我们应该时刻质疑自己的假设,而且千万不要假设自己第一个设计是完美的。

原文:https://realmensch.org/2017/08/25/the-parable-of-the-two-programmers/

相关推荐