成为一个程序员要花多长时间

理解专业程序员

成为一个程序员要花多长时间 

http://book.csdn.net/ 2007-3-27 10:18:00

图书导读

当前章节:成为一个程序员要花多长时间

·目录

·前言

·透明推荐序

·残障人士能成为成功的程序员吗

·专业程序员有哪些范式

·一个专业人士能从这个职位中感到快乐吗

成为一个程序员要花多长时间

对于有些事情，似乎每个人都是专家。教学就是一个好例子。任何人，只要智商超过80，又懂得一点儿什么东西，似乎都可以当老师。至少美国的教育体系就是建立在上面这个理论上的。在美国，但凡你敢对一个教授说，他的课堂教学还有可改进的地方，那他就会感到羞辱、恼怒，还很可能采取法律行动。

还是在美国，每个人都是当招待的专家。在欧洲，一个侍者可能要经过10年，甚至20年的训练，才能获准在一个一流饭馆服务。在美国，只要按照广告应征，在小臂上搭一条毛巾，那就是侍者了。

编程是另一个不缺乏专家的领域。按照标准看法，6个星期的“培训”就足以把一个人提升到“专家”层次，该人不必再学习任何新的知识，即具有设计在线生命救援系统的资格。如果你看到一条广告招收“有经验的”程序员，那意思往往就是一年或者两年经验。实际上，如果谁有15年的编程经验，人们倒会觉得这人简直是个智障。如果他真有一点点智力的话，那总应该在14年前就学会了全部编程知识。在此之后，他就早该做腻了这一行，去换个管理呀，销售呀之类的职位了。

先别忙着嘲笑持这种观点的人，首先我们还是应该承认，15年的经验，就其自身而言，在编程方面不一定就能教会你任何东西。我认识一些有“15年经验”的美国侍者，甚至不知道餐前如何在餐桌上放盘子。我也知道一些有“15年经验”的美国大学教授，甚至教不会小狗摇尾巴。同样，我也认识一些有“15年经验”的美国程序员，他们仍然会在一个多程序访问的系统中，在更新直接存取主文件（master file）之前，就给事务文件（transaction file）排序。

理解专业程序员第1章对专业人士来说，有哪些重要问题如果说这个例子还太难懂，那我就来列举几个前两天读“有经验的”程序员写的代码时发现的问题：

1. 在做整数除法时，有些人不懂“余数”是什么东西！

2. 为了把一个取值在0~5的变量转化成取值在1~6的变量（用于FORTRAN语言的下标），有人用了5个IF语句，再加上5个赋值语句！

3. 在写COBOL程序的时候，有些人不用“ELSE”子句，原因是“这不一定管用”。

4. 在写PL/I程序的时候，有些人从来不用变长字符串，原因是“这个不够高效”。

5. 有些人根本不写子程序，原因是“这太复杂了”。

这个单子能够无限地写下去。这里的要点不是在于，居然有这么多看似专业程序员的人在四处丢人现眼，而在于，没有几个管理者知道，正在和自己打交道的到底是“他们”中的一员，还是“我们”中的一员。

这和美国侍者的处境特别相似。在美国，很少有人曾经享受过专业侍者的服务，所以即使人们真正遇到了一个专业侍者，他们也无从辨别。或者这样说更好，他们根本无法意识到，他们心目中的“标准”侍者其实还处于“亚专业”层次。

同样，除非你自己就是一个胜任的程序员，否则也就很难衡量一个程序员的工作质量。世上有很多可怜的企业，这些企业中从来没能长期留住一个真正胜任的程序员，因此他们也就没有一套标准来衡量程序员的专业性。这些企业的标准就是把庸人当成奇才。而这样的标准也千奇百怪，各地均不相同，甚至同一公司中的不同部门也不相同。

每次我到一家新公司去做咨询顾问的时候，我都提前让经理给我看一些典型代码。经理们往往都不敢相信我真是要看代码，我总得坚持索要好几次才能得手。只要看一小段代码，我通常就能对该公司的工作环境具有相当准确的了解。有时候我说得特别准，管理层听了都大吃一惊，以为此前我跟员工们私下谈过话。

经理们自己永远也不看代码。代码之于经理，如同脏盘子之于领班侍者。一旦你从那个垃圾堆里提升出来，你就再也不碰那些垃圾了——开玩笑碰一下都不成。

有一回，在大学里的时候，我们学生提议，教授们也应该和学生一起参加硕士生考试，好给学生们做个榜样、立个标准。2/3以上的教授对此满是惊恐，敬谢不敏。他们自己也经过20多年的考试折磨，再也不愿意回到考生的位置上去——这会让他们想起从前卑微的地位。

同样，在我们的行业里经理不愿意编码，这说明写代码这个职业在人类等级体系中的地位略高于盗墓者，低于管理层。对于这样的思考方式来说，编写代码不可能构成一种独立的技艺，不可能是一种天分，也不可能是一种有着自身地位的体面职业——所谓体面，就是说不必和盗墓呀，管理呀之类的在同一个尺度下衡量。只要这种态度在数据处理行业还处于主导地位，那就仍然会有6个星期培养出来的专家，也还会有那些经理——他们甚至不愿倾听公司高薪聘请的、有15年经验的程序员说话。

当老师、当侍者、当程序员，这3件事有什么共同之处吗？为什么人人都觉得自己能够像专业人士一样做这3件事？首先，这些工作似乎是容易理解的，因为很多挺普通的人都有过相关的经验。每个人都或多或少曾经教过别人。每个人都做过把盘子放在桌上，或者收拾脏盘子的事。但是不是每个人都曾经在一个活人大脑上做过手术，也不是每个人都曾经在陪审团前为一个案件辩护。

但是编程序又是什么情形呢？当然了，并不是每个人都写过程序，对不对？也许不是每个人都写过，但是似乎每个经理、会计、工程师，或者其他大学毕业的专业人士都写过程序。编程课程在大学里相当风行，在很多职业教育中，这也是必修的课程。比如说，IBM在20年来，在行政人员培训班中就设置了一定的“编程经验”。

我不太清楚现在IBM的行政人员培训班的具体课程内容，但是有好多年这门课程中包括了那个著名的“曼哈顿问题”，作为唯一的编程练习。在美国，数据处理课程的主流入门教科书大多会讲到这个“曼哈顿问题”，如果读者中有人不巧没学过这个，我就按照教科书上的写法，在这里重复一遍：

问题是这样的：据说在1627年，白人们用24块钱买了曼哈顿岛。如果这笔钱被存入一个银行户头，按年利率4.5%计算，今天会有多少钱？

（如果4.5%的年利率偏低的话，那是因为这道题是1956年出的，从那时起就被一代代的作者在不同的教科书中抄来抄去。）

这道题的“解法”，如果抛开一些无关紧要的细节，按照FORTRAN语言编写，那就是这样一个循环：

I = 1627

PRINC = 24.00

2PRINC=PRINC*1.045

I = I + 1

IF(I-IYEAR)2,1,1

1WRITE (3,601) PRINC

至少有三四百万名学生学会了这个“解法”，这之中包括从行政人员到大学新生的各种人。对于其中的一些人，以上代码就是他们“写过”的唯一程序，但是这就让他们有足够资格判断编写一个操作系统、一个劳动力部署系统、一个零件需求管理模拟器、一个在线处理控制器，或者无论什么你想得出来的系统的复杂度。而且，当然了，在行政人员的课程中，每个学生还有一个专业程序员作为辅导，“好帮助他们处理细节问题”。

其实呢，曼哈顿问题确实可以作为一个出色的工具，教给行政人员关于编程行业他们应该知道的最重要的一课。假设让他们编写了以上那么一段程序，也对他们承认这确实是问题的一个“解法”。然后你就问问他们，编这个程序花了多少时间，运行该程序又要多长时间，再问问他们，觉得这些数字“好不好”。

当他们交了作业，也总结了感受，你就让他们看看下面这个程序，告诉他们这样的代码就能获得同样的结果：

PRINC=24.00*(1.045**(IYEAR-1627))

WRITE(3,601)PRINC

对他们比较一下编程时间和运行时间。你大概能够发现这后一个程序只需要1/5的编程时间，和1/100的运行时间，当然具体的比例在不同的环境下不一样。然后你就问他们：“如果对这样一个最简单的程序，两种不同的代码之间能够具有5倍，甚至100倍的差别，那么，如果一个专业程序员和一个业余程序员编写同样一个操作系统的话，又会产生多大差别呢？”

如果给行政人员上了这样一课，那么这种给他们扫盲、让他们理解编程是怎么回事的课程也许能够利大于弊。但是目前这一类课程的主要目的，虽然从来没有明言，但其实是这样的：“编程并没有那么复杂。练习几个星期，哪怕是我也能成为编程专家。”

为了把编程当成一种正规职业对待，公众——也包括程序员自己——都应该通过某种方式受到教育。他们必须懂得这样一个道理：即使是15年的经验，对于学习编程知识来说也不一定就够用——除非这位学习者特别一心一意。