龙 2010年01月31日 星期日 03:19 | 1607次浏览 | 2条评论
触动我观念的文章,第一次知道程序员中的谚语 "Eat Our Own Dog Food"
[原文] http:
程式设计师的生产力之谜
很多人都听说过,同样是写程式,一个顶尖程式设计师和一个普通程式设计师之间的生产力可以有十倍甚至百倍的差距。这是其他行业很少见到的现象,于是不禁令人纳闷,为什么会这样呢?
其实单就解决同一个问题的coding能力来说,差别还不至于这么巨大。我在高中参加奥林匹亚和大学参加ACM比赛时,已经遇过全世界数一数二的coding高手,这些人每天都在练习解题和实做各种复杂的演算法和资料结构,随便说一个演算法都能直接把code透过肌肉记忆反射出来给你。他们能在数十分钟内想出高效率的演算法并写成程式解决一个复杂的难题,即使我高中时已经花了一整年在训练,依然不是他们的对手。这些人除了绝顶聪明外,每个人在高中时少说也写过至少十万行的code。但我发现,即使他们能解一般人解不出来的问题,打字快到键盘会冒烟,在做一个大系统时,这方面的差距还不一定会如此明显。
所以我想,除了先天的智商和后天对于写程式的熟悉度与经验外,一定还有什么因素造成巨大的生产力差异。
我后来发现,程式设计师和其他行业有个很大的不同点:一般行业只能在现有的工具上磨练自身的技术,但程式设计师除了磨练技术外,还可以独自创造、修改自己使用的工具;换句话说,程式设计师的能力就是在电脑上创作出更好的软体,不但能便利他人,也同时能增进自身使用电脑的工作效率。举例来说,理髮师能磨练使用剪刀和设计髮型的技术,但理髮师并不知道怎么发明及制造新的剪刀让自己更有效率的剪头髮;电机、化工、土木工程师要设计IC、化学制程、建筑结构,但他们得依赖电脑软体才能设计,并且靠许多大型机器和工具才能生产,即使想提昇自身的工作效率,也不是自己一个人想做就能办到的。但软体工程师就不同了,我们只靠一台电脑就能工作,我们的工具是软体,我们的产出也是软体,我们的所依赖的一切都是软体,只要自己愿意投入心力,随时可以修改每天使用的工具和系统让自己更有效率的工作。
这一点可以说是程式设计师的先天优势,也是顶尖的程式设计师和普通程式设计师的生产力差距的关键。
我发现厉害的程式设计师常有种共同特质:写工具给自己用,解决自己日常工作碰到的问题或改善自己的工作效率。英文有句话叫eat one’s own dog food,字面上意思是说一家公司应该要吃自己做出来的狗食,实际上是引申为一家公司应该要在内部用自己的产品解决自身的问题,才能发现真正的问题,并且说服人这东西真的很实用。Google是奉行「吃狗食」原则的典型公司,Google内部有一个独立的搜寻引擎搜寻公司内部网路的资料,新技术也都能在上面先行测试;Google内有独立的gmail、google docs,都在对外公开前先让内部的人实际用上好一阵子;Google甚至做了自己的Linux distribution给工程师用、自己的compiler、自己的浏览器…。
会这样做的动机其实很简单:如果我每天都要花10分钟手动做同样的事情无数次,为什么不花一个小时写个程式把这件事情自动化,以后可以省下更多时间做点真正有意义的事;如果我每天都要用这个别脚的软体,忍受他设计上的不便,为什么不想法办改善它或自己做一个呢?
程式设计师每天都用电脑在工作,尤其做一个系统时常常需要花时间做一些琐碎的工作,像是编辑设定档、把一些档案搬来搬去、重开伺服器、清除暂存档…等等。这些工作通常不难,但可能步骤繁杂,或是每个步骤都要等待它慢慢完成,累积起来每天就很容易浪费许多时间手动做这些无趣的事情上。
出于「懒惰」的美德,顶尖的程式设计师工作时想的不只有产出最终产品就好,而是如何花最少力气最少时间把产品做到最好。但这件事说来容易做来难,能不能实行往往跟程式设计师工作的系统环境有很大关系。
如果要说我高中时期最大的收穫是什么,我想有两件事的重要程度不相上下:一是我确认了自己对写程式的热情,并且花了足够多时间打好基础;二是我在这段时间内摸熟了Linux,并且爱上了UNIX世界工作的哲学。
UNIX可以说是一个非常适合程式设计师工作的天堂,UNIX的工作哲学(泛指所有UNIX like的系统,像是Linux、BSD、Mac OS X..等等)是提供许多小工具,每样小工具只做一件事,使用者可以合併使用多种工具完成复杂的工作。此外,UNIX的工具都是以command line为介面,非常适合写script做自动化的操作。而在Windows的世界中则完全不同,Windows上的软体倾向于提供整合式的GUI环境,把所有相关或可能会用到的功能全都一手包下,虽然方便使用者,可以点几个按钮就自动做完所有事情,但对于程式设计师来说其实不是一件好事。
以写程式的工具来说,在UNIX下可以选自己喜欢的文字编辑器,不管是Vim或Emacs,也可以选自己喜欢的compiler,可以用makefile加上command line工具自动化整个程式编译、测试、执行的流程,并且随时都可以加入shell script或是perl script把开发流程中琐碎的工作一併自动处理,不管需求有多么特别,这种完全自订的流程弹性可以说是无限大。
但在Windows环境,主流开发软体以整合开发环境(IDE)为主,像Visual studio这种无所不包的巨兽,对于新手来说按一个键就能搞定一切,不用去想底下的细节,实在方便得很。可是依赖于IDE却有个致命缺点:只要是IDE的设计者一开始没考虑到的事,你就没办法做。
举例来说,早期visual studio不支援版本控制系统(version control system)时,程式设计师就很难把版本控制整合到开发过程中(例如说在编译成功时自动commit、或是自动加入新的原始码…);即使到现在visual studio已经支援了一些常见的版本控制系统,用它的人依然要看这个支援的清单包含哪些系统,如果是想用新的系统,或是用非标准的方法使用这些系统,恐怕只能遗憾的两手一摊什么事也不能做。有些IDE虽然有提供plugin功能(像是Eclipse),但其实也没好到哪,因为IDE庞大无比,写plugin的难度和所需时间远高于使用者手动完成这些日常琐事所花的力气,自然不会有多少人愿意去做。
简单来说,用IDE的话,程式设计师没办法掌控自己用的工具,也没办法改善开发流程中的问题,开发效率的极限很自然会被IDE限制住。但UNIX上的环境就不一样了,採用多种工具的组合让自己能掌控开发流程中每个步骤。因为每个步骤和所用的工具都是透明的,只要有需求或是发现哪里可以改善,很容易可以从满手的工具中抓出一个来解决,或是写个迷你的script来自动处理较复杂的工作。即使哪天有新的小工具出现(例如说一个新的版本控制系统),因为每个小工具都是独立运作,靠程式设计师自行整合的,所以也比较容易把旧的「零件」替换掉。除此之外,open source兴起后,带有原始码的系统更带给程式设计师一个「完全控制」的机会,除了能替换零件外,有能力的人还能直接对零件本身做修改以符合自己的需求。种种因素加起来,让程式设计师不再被单一个工具能力所限制,而是手中握有无数可以自由运用的筹码,唯一的限制只有自身的创意和热情而已。
我一直觉得念资讯系的人不应该依赖于用IDE写程式,当然这并不只是因为「用command line才是真男人」这种geeky的理念,而是念资讯系的应该要能擅长于「把电脑能做的事交给电脑做」。今日的软体介面大多是以多数的日常使用者为目标,虽然方便操作,但设计者不可能把所有使用者可能会想做的工作列表做出各种排列组合放在选单里。如果是设计者没考虑到的功能,使用者往往也只能手动慢慢处理。但程式设计师和一般使用者是不同的,程式设计师的能力就是和电脑沟通,让电脑用我们想要的方式帮我们完成工作。如果我每天要重复按照顺序按100个不同的按钮,为什么不写个程式自动按这100个按钮?
我跟一些人聊过这个想法,但典型的反应是「正事都做不完了,哪里有时间先做一个工具?」
但我觉得很讽刺的是,正是因为抱持这种观念才会让生产力低落,所以让正事做不完,时间越紧迫就越不敢花时间做这种没有立即产出的事情。相反地,如果在意识到自己已经三番两次手动重复执行同样的冗长工作时,就应该静下来好好想想是不是有什么办法可以让电脑来做这些事,只要常有这种想法,写这些script和小工具所节省下来的时间和自己得到的经验是一辈子都用得上的。
现在有许多open source软体一开始都只是程式设计师为了方便自己所写的小工具,在做正事的时候拨出时间先做好工具,然后不知不觉可能就成了伟大的软体。最有名的例子是Knuth为了写他的The Art Of Computer Programming,他竟然先重头自己打造一个针对数学环境设计的排版系统,最后就成了着名的TeX。他不但完成了电脑科学界的圣经,还「顺便」完成了一个经典的排版系统并分享给全世界使用。
如果持续抱持着这种态度写程式,说不定你我也能成为下一个Knuth呢? (笑)
Zeuux © 2024
京ICP备05028076号
回复 曾睿 2010年02月01日 星期一 14:28
回复 龙 2010年02月02日 星期二 06:34