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

【CSDN 编者按】有两个程序员分别设计同一个系统：一个用了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/