转载

两个程序员的故事

两个程序员的故事

从前,有两家互不知晓的公司,一家叫做“自动会计应用协会”,另外一家叫做“统一计算资本公司”。他们同时决定开发一种提供相同功能的程序。

“自动”雇佣了一位分析程序员,艾伦,来解决这个问题。

而“统一”决定试一下新来的初级程序员查尔斯,看看他是否有真本事。

艾伦做过一些复杂项目,有着丰富的经验,决定采用PQR结构化方法来开发这个程序。于是他找到部门经理,要求增派3名程序员组成一个项目小组。这个小组于是开始工作,捣鼓出初步的项目分析报告。

“统一”这边,查尔斯抽了点时间想了一下需要解决的问题。同事们常常看到查尔斯把脚翘在办公桌上喝咖啡。偶尔见到他坐在电脑前,但是那有节奏的键盘声告诉别人他其实在玩小蜜蜂。

不久,“自动”的小组开始编写代码了。程序员们一半的时间用来编写编译代码,另一半的时间待在会议室里,讨论模块间的接口设计。

查尔斯的同事发现他终于不再玩小蜜蜂,而是一半的时间把脚翘到办公桌上喝咖啡,另一半时间在纸片上涂写着什么。他好像不是在纸上玩“井字过三关”,但看起来不像是在写有用的东西。

两个月过去了。“自动”的小组终于发布了项目时间表。计划再过两个月,他们就会发布程序的测试版本。然后再经过两个月的测试和改进,就可以发布完成版了。

此刻,对于查尔斯的游手好闲,他的经理再也看不下去了,他决定批评查尔斯一下。但当经理走进查尔斯的办公室时,他却惊讶地发现查尔斯在电脑前正埋头写代码。于是他决定把批评先放一放,随便跟查尔斯聊了一下就离开了。然而从此他更加注意观察查尔斯的表现,想借机批评查尔斯。不过不愉快的对话并没有发生,他很高兴地发现查尔斯一直在写代码。人们偶尔发现查尔斯推迟了午餐,且一周还主动加2、3次班。

第三个月的月底,查尔斯宣布他已经完成了这个项目。他提交了500行的程序。程序清晰可读,测试中符合所有的功能要求,甚至具备了一些更加便利的功能,极大地提高了程序的易用性。测试后,程序除了有一处疏忽外,表现得非常好。

“自动”的项目小组到此时已经将4个主要模块中的2个开发出来了。在这些模块被测试的同时,小组继续开发其余的模块。

又过了3周,艾伦宣布提前一周完成了程序的初级版。他提交了一份清单,列举了尚需解决的一些缺陷。测试中,客户发现了一些清单上没有的错误和缺陷。艾伦解释说这是意料之中的,毕竟这只是一个初级的版本,有错误很正常。

又过了两个月,项目小组完成了程序的正式版,包含了2500行代码。测试中发现,这个版本完成绝大部分的最初需求。程序功能上有一两处遗漏,且对于数据输入的格式要求非常严格。但公司最终决定使用这个程序,他们可以训练打字员严格按照要求输入数据。对于那些遗漏的功能,交由维护程序员去添加。

后记:

一开始经理对查尔斯的能力印象深刻。可当他阅读源代码的时候,发现原来问题比自己开始想象的要简单得多。现在看来,这种难度哪怕对于初级程序员来说也明显太低了。

的确,查尔斯平均每天产出了5行代码,这略高于平均水平。但是考虑到项目复杂度是如此的低,略高的生产率也不足为奇。而且经理对他头两个月的游手好闲记忆犹新。

业绩评估中,查尔斯薪水的涨幅大概是同期货币通货膨胀率的一半,他也没被提升。又过了一年,他感到沮丧而离开了“统一”。

“自动”这边,艾伦因为按时完成这个项目而受到表扬。他的主管翻了几页源代码,发现代码符合公司的结构化编程规范。但他很快便放弃了阅读代码的想法,因为它看起来相当深奥。他现在意识到项目的复杂度远比当初自己设想的高,于是他再一次夸赞艾伦的成就。

项目小组平均每人每天写3行代码,刚好是平均水平。但考虑到问题的复杂度,有平均水平就非常不错了。艾伦被大幅加薪,作为奖励,他被提升为系统分析员。

英文原文: The Parable of the Two Programmers

正文到此结束
Loading...