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


又经过大约两个多月的时间 , 程序的正式版本开发完毕 。 它由大约2500行代码组成 。 测试时 , 它似乎满足了大部分项目需求 。 但是它削减了一两个功能 , 而且对输入数据的格式非常挑剔 。 然而 , 公司还是决定上马该程序了 。 他们可以随时对数据录入人员进行培训 , 让他们严格按照要求的格式输入数据 。 此后该程序移交给了一些负责维护的程序员去补全缺失的功能 。
后记:
起初 , Charles的上司对他在这个项目上的表现还是比较满意的 。 但当他通读程序源代码的时候 , 他发现这个项目真的比他最初想象的要简单得多 。 现在看来 , 即使是对一个初学编程的人来说 , 这显然也不是什么难事 。
Charles每天确实产出了大约5行代码 , 这或许是略高于业内平均水平 。 然而 , 基于程序是这么简单 , 他的表现也就并没有什么特别了 , 而且他的上司还记得他那两个月的“摸鱼劣迹” 。
在下一次薪酬调整时 , Charles得到了加薪 , 加薪幅度约为这一时期通货膨胀率的一半(很可怜吧) , 公司没有给他升职 。 大约一年后 , 他变得心灰意冷 , 离开了Consolidated 。
在Automated公司 , Alan因如期完成了项目而受到嘉奖 。 他的上级看了看他们编写的程序 , 他浏览了几分钟 , 恩 , 是遵守公司关于结构化编程的标准的 。 然后他很快就不再继续尝试往下看了 , 这程序看起来似乎很难理解 。 这时他意识到 , 这个项目确实比他原先设想的要复杂得多 , 他再次对Alan的成就表示祝贺 。
Alan团队的每个程序员每天产出3行多的代码 。 这在业内大约是平均水平 , 但考虑到这个项目所要解决的问题的复杂性 , 可以说是很不错的产出啦 。 Alan因此获得了丰厚的加薪 , 并被提升为系统分析师 , 以表彰他的成就 。
来自Tim Mensch的评论
我曾经是一名年轻但是聪明的程序员 , 这个故事令我产生了强烈的共鸣 。 即使在我还是个职场新人的时候 , 我也能做到令很多资深开发人员都感到有挑战的事情 。 在我的第一份工作中(作为游戏开发者) , 我的经理说我在几天内创建的代码 , 感觉比一个更有经验的开发者经过几个月的推敲后完成的代码都要好(从物理意义上讲) 。 在我的第二份工作中 , 我对一个有十年以上经验的高级开发人员编写的工具程序进行了优化 , 使其只需几分之一秒就能完成一个任务 , 而不用花费几分钟 。 我的整个职业生涯充斥了这样一连串的奇闻轶事 。
在我从事编程以来的多年开发和学习经历中 , 我意识到经验确实很重要 。 但是 , 底层技能也同样重要 。 实际上 , 就像上面讲到的两个程序员的寓言一样 , 底层技能可能比经验更重要 , 我认为这个事实已经被许多当代的开发者忽略了 。
话虽如此 , 我也曾经踩过坑 , 跟上文提到的第二个开发者类似 , 创建了一个比实际所需要的复杂得多的系统 。 我知道一个复杂的解决方案 , 并且知道自己可以实现它 , 但这并不意味着它就是最好的解决方案 , 我需要时不时地提醒自己这个事实 。
于是 , 我尝试做出妥协 , 甚至质疑我自己的解决方案 , 持续寻找能够改进和简化的方法 。 我曾遭到指责:因为我倾向于花费更多的时间去思考一个问题 , 而不是仅仅用显而易见的方法去解决它;我希望能找到更简洁的方法去解决问题 。 因为花了很多时间思考 , 看起来好像不务正业 , 但是充分地思考可以让我产出更好的结果----代码量更少 , 更健壮、更可扩展而且更容易阅读 。
这就是为什么我认为上面这个寓言如此重要的原因 。 开发经验固然重要 , 但在项目设计和实施上的技能都可以完胜经验 , 如果你同时具备经验和技能 , 就可以实现相当的奇迹 。 只要你持续质疑自己的想法并持续思考如何更好地完善它 , 而不要一味地认为自己的第一个设计构思就是足够完美的 。
译者:张茉茉


推荐阅读