程序两个程序员的寓言:2500行代码的程序,一定比500行的好吗?

神译局是36氪旗下编译团队 , 关注科技、商业、职场、生活等领域 , 重点介绍国外的新技术、新观点、新风向 。
编者按:2500行代码的程序一定比500行代码的程序好吗?写出简洁、高效、高可用的程序的开发者黯然离场 , 搞出庞大、复杂又难用的程序的人倒能加薪升职?究竟开发者的工作应该如何进行评价?来看看下面两个程序员的故事吧 。 本文译自RealMensch , 作者 Neil W. Rickert , 北京联盟_原标题为“The Parable of the Two Programmers” 。
程序两个程序员的寓言:2500行代码的程序,一定比500行的好吗?
图片

两个程序员的寓言
很久以前 , 有两家公司 , 分别是"Automated Accounting Applications Association "和 "Consolidated Computerized Capital Corporatio" , 他们决定 , 需要一个程序来执行自己公司的某项业务 , 但这两家公司并不知道 , 对于他们的业务需求来说 , 要开发的程序是完全一样的 。
Automated雇用了一位程序员分析师Alan来解决他们的问题 。
与此同时 , Consolidated决定让他们新招聘的一名初级程序员Charles来负责这项工作 , 看看他是否真的那么优秀 。
Alan曾经有过操刀艰难的编程项目的经验 , 所以他决定使用PQR结构化设计方法 。 考虑到这一点 , 他要求部门经理再指派三名程序员作为编程团队 。 然后 , 这个团队就开始工作了 , 扑到了铺天盖地的初步报告和问题分析上 。
再看Consolidated这边 , Charles没忙着动手开干 , 他花了一些时间思考这个问题 。 Charles的同事们注意到 , 他经常坐在桌前 , 把脚抬起来放在桌子上 , 喝着咖啡 。 偶尔也会看到他在电脑前忙活 , 但同事们从他敲击键盘的节奏就能看出 , 他其实是在玩《太空侵略者》的游戏 。
这时 , Automated的团队已经开始写代码了 。 程序员们大约用了一半的项目时间来编写和编译代码 , 其余的时间都在开会 , 讨论各种模块之间的接口问题 。
而Charles的同事注意到 , 他终于不再沉迷《太空侵略者》了 。 他现在要么就是把脚架在办公桌上喝咖啡 , 要么在小纸片上乱涂乱画 。 他写在小纸片上的字迹很潦草 , 当然看起来不是在玩Tic Tac Toe(一种游戏) , 但也没有什么意义 。
两个月过去了 , Automated公司的团队终于发布了项目实施时间表 。 再过两个月 , 他们将发布一个测试版的程序 。 然后再经过两个月的测试和优化 , 便会得到一个完整的最终版程序 。
另一头 , Charles的经理一直看着Charles上班摸鱼 , 已经厌烦了 , 他对Charles失去了耐心 , 决定和他摊牌 。 但当他走进Charles的办公室时 , 却惊讶地看到他在电脑前忙着输入代码 。 他决定等等看会发生什么 , 所以打了个哈哈 , 然后离开了 。 他开始密切关注Charles , 以便抓住机会当面好好教训他一番 。 但是预期中那令人不快的对话并没有出现 , 因为他很高兴地注意到 , Charles似乎大部分时间都在忙碌 , 甚至有人看到Charles忙得连午餐都很晚去吃 , 而且一周有那么两三天 , 下班后他还会留下来加班 。
三个月结束时 , Charles宣布他已经完成了这个项目 。 他提交了一个包含500行代码的程序 。 程序似乎写得很清楚 , 经过测试 , 它可以满足项目既定的所有需求 。 事实上 , 它甚至还有一些额外的便利功能 , 可能会显著提高程序的可用性 。 该程序投入实际测试使用后 , 除了发现一个可以快速纠正的疏忽外 , 表现良好 。
到这时 , Automated的团队已经完成了项目所需的四个主要模块中的两个 。 这些模块目前正在进行测试 , 而其它模块已经完成 。
又过了三周 , Alan宣布 , 初级版比原计划提前一周完成 。 他提供了一份待纠正的缺陷列表 。 该程序开始进行实际测试使用 。 除了缺陷列表中列举的问题 , 用户还发现了一些其它的错误和缺陷 。 正如艾伦所解释的那样 , 这并不奇怪 。 毕竟这是一个初级版本嘛 , 有错误是意料之中的 。


推荐阅读