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

oscarlo

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

作者 | Neil W. Rickert

译者 | 弯月
责编 | 屠敏
$ Z. r2 P& M( A6 j; m4 a出品 | CSDN（ID：CSDNnews）
以下为译文：
很久很久以前，“自动会计应用协会”（后面简称“自会”）和“综合计算机资本公司”（后面简称“综计”）两家公司素不相识，却在同一时间里认为他们需要一个程序来执行同一项服务。
自会聘请了程序员兼分析师Alan来帮他们解决问题。
与此同时，综计决定聘请一位入门级程序员Charles来解决这个问题，看看他的水平是否真的像他吹嘘的那样。
Alan经历过难度很高的编程项目，他决定使用PQR结构化的设计方法。为此，他要求部门经理再指派三名程序员组成开发团队。于是，这个新成立的团队开始了紧张的工作，着手查看初步报告和问题分析。
反观综计，Charles花了很长时间反复思考这个问题。他的同事发现，Charles经常翘着腿悠闲地喝咖啡。偶尔有人看到他坐在电脑前，但是同一个办公室的同事说，从Charles按键的频率推测实际上他在玩太空入侵者。
时间一天天过去，自会的团队已经开始编写代码了。这些程序员们花了一半的时间写代码和编译代码，还有一半的时间里他们开会讨论各个模块之间的接口。
2 q( b0 o% z8 U同一个办公室的同事发现Charles终于不玩太空入侵者了。现在，他除了悠闲地喝咖啡，就是在纸上涂涂改改。虽然他的涂鸦不是玩五子棋，但似乎也没有多大意义。
  m  f" S5 ~7 F  I两个月过去了。自会团队终于发布了开发时间表。再过两个月，他们就可以完成测试版的程序。之后，再经过两个月的测试和加强，就可以交付一个完整的程序了。
经理终于对终日无所事事的Charles忍无可忍，他决定当面质问他。但是，当他走进Charles的办公室时，却意外地发现Charles正在忙着写代码。于是，他决定迟些再质问他，然后打了个招呼就匆忙离开了。从那以后，经理开始密切关注Charles，他打算一旦找到机会，就当面质问Charles。然而，他却迟迟没有找到机会，相反他发现Charles一直都很忙碌。他甚至看到Charles有时忙得连吃午饭的时间都没有，每周还有2-3天在加班。
  x  |: z$ Y% ~' S& A8 m4 @7 e第三个月结束的时候，Charles宣布他做完了这个项目。他提交了一个只有500行代码的程序。看起来这个程序写得很清晰，而且经过了良好的测试，符合规范中的所有要求。此外，这个程序还有一些额外的功能，大幅提高了该程序的实用性。在测试的时候，除了一个小纰漏（很快就改好了）之外，整个程序表现良好。
- ?( z8 e) Q& T  o1 [) t与此同时，自会团队已经完成了他们的程序所需的四个主要模块中的两个。这些模块现在正在进行测试，而其他模块已完成。
又过了三个星期，Alan宣布初步版本已提前一周准备就绪。他提出了希望修改的缺陷列表。这个程序还在测试中。除了Alan提出的列表外，用户还发现了很多Bug和缺陷。Alan解释说，这属于正常现象，毕竟这只是初步版本，肯定会有很多Bug。
又过了两个月，自会团队完成该程序的生产版本，大约包含2500行代码。经过测试，该程序似乎满足大多数的原始规格，却忽略了一两个特征，而且对于输入数据的格式也非常挑剔。但是，自会决定安装该程序。他们可以训练数据输入人员，按照要求的格式严格地输入数据。最后，这个程序移交给了一些维护人员，由他们负责缺少的功能。
续集
+ l# I6 C# \) ~8 V+ Z- w起初经理对Charles刮目相看。但是，当阅读了源代码后，他发现这个项目实际上比他原本想象的简单许多。现在看起来，即使对于新手程序员来说，这也算不上很大的挑战。
Charles每天大约可以写5行代码，这可能略高于平均水平。但是，考虑到程序的简单性，这也不足为奇。此外，经理还记得Charles游手好闲了两个月呢。
在业绩评审中，公司给Charles涨了工资。一半原因大概是因为通货膨胀。但是，Charles没能得到晋升。大约一年以后，Charles有些失望，于是他离开了综计。
在自会，由于如期完成了项目，Alan受到了大力褒奖。他的主管检查了他做的程序，他大概浏览了一下，发现公司有关结构化编程的标准都实现了。然而，很快他就放弃了阅读该程序的源代码，因为太难懂了。所以，他觉得这个项目实际上比他原本设想的更为复杂。然后，他再次向Alan表示了祝贺。
1 ?6 n9 T8 ]# d; z* B/ H这个团队中的每个程序员每天可以写3行代码。这与平均值很接近，但考虑到问题的复杂性，所以可以认为他们表现优异。为了奖励他的成就，Alan获得了高额加薪，并晋升为系统分析师。

& u5 X) c7 l; N$ i; z0 B( qTim Mensch的评论
- z7 n* o- Y; C0 m4 P2 }曾经我也是一名年轻聪明的程序员，这个故事引起了我强烈的共鸣。即使在职业生涯的早期，我也可以完成很多高级开发人员所面临的挑战。在我的第一份工作中（作为一名游戏开发人员），我花了几天时间写完了代码，我的经理说我写得比那些经验丰富的开发人员花几个月写的都好。在我的第二份工作中，我优化了一个由有10年经验的高级开发人员编写的工具，经过我的优化，原来需要几分钟的任务只需要不到1秒就完成了。在我的整个职业生涯中，这样的例子层出不穷。
多年以来的开发和学习，让我意识到经验确实很重要。但基本的技术力也同样重要。事实上，上面这则寓言故事说明，基本的技术力比经验更重要，我认为当代开发人员没有认清这个事实。
, p) [6 u' ^6 V# e- ^+ L6 o( W$ c话虽如此，偶尔我也会犯与Alan同样的错误，创建一个复杂得毫无必要的系统。我能想到并且能够实现一个复杂的解决方案，并不一定意味着它就是最好的解决方案，我需要不断提醒自己这一事实。
所以，我一直在努力做出妥协，有时甚至质疑我自己的解决方案，强迫自己寻找改进的方式，或简化的方法。有时，有人会觉得我花了太多时间来思考某个问题，为何不直接用显而易见的方式来解决，其实我是希望找到一种更简洁的方式来解决问题。花在思考上的时间让人感觉没有在“工作”，但是我可以通过思考找到更好的方式——用更少的代码，实现更强大的功能，且具备可扩展性，还便于阅读。
这就是为什么我觉得上述寓言故事如此重要。经验很重要，但设计和实现方面的技术力可以胜过经验，如果你同时具备经验和技术力，那么就可以出色地完成工作。我们应该时刻质疑自己的假设，而且千万不要假设自己第一个设计是完美的。
& y+ H" ~! e" N原文：https://realmensch.org/2017/08/25/the-parable-of-the-two-programmers/
+ Q% S2 X! A0 \4 x: z【End】

: D8 F% L& I5 u& b  D 热 文 推 荐
) B- i  }( e8 V, a. w& A
戳他↓↓↓
! E9 I( V  E: G" A9 N, q1 B6 ~
* |+ l5 h8 F2 l  n+ [+ y- b7 E% v
System.out.println("点个在看吧！");
% X: T8 u3 k6 k1 c0 H% dconsole.log("点个在看吧！");
0 d( R$ Y8 W$ I1 L7 [3 tprint("点个在看吧！");
printf("点个在看吧！\n");
1 }$ X8 r& {6 y% ^cout