说说软件开发这个职业

    有时，一个问题的真正价值并不在于找到答案，而在于通过考查这个问题引出其他或许更有价值的问题。另外，有时候发现一个无人问津的问题，也可能会帮助我们看到一些未被发现的机会，从而引出更深远、更有价值的发现。

我已经“搞软件”很长时间了，我觉得我们这个行业已经到了“回头看看”的时候了，此时回顾一下我们工作的基本性质可能是一件非常有用的事情。

人类制作软件已经有多久的历史了

像很多问题一样，这个问题的答案是“要看情况”。制作软件的概念都包括什么？是否包括最早期由绕线PC板和交换管构成的编程？是否包括提花织机？

    也许不包括。但使用穿孔卡片和大型主机进行数据处理的那段时期是否应该包括进来呢？那时人们使用穿孔卡片或磁带输入，使用打印机输出，没有交互，没有VDT，为了看看程序是否正确运行，需要通宵等待。

    为了便于本书的讨论，我认为软件制作应该从20世纪70年代中后期开始算起，那时小型桌面系统刚刚问世，我们开始开发供人们直接使用的交互式软件。

    这并不是说我认为数据处理不够重要、不够有趣，或不够复杂，只是过去他们的数据处理方法与我们现在的数据处理方法之间的差别实在是太大了，以至于我看不到其间存在智慧的传承。这就像是骑马与开车一样：二者都是复杂的活动，都需要知识和技巧，但学会了一样实际上并不能帮助你学会另一样。

    但是先等一下！面向对象（OO）语言和技术的出现又该如何看待呢？它们与过去一度盛行的过程语言（例如C和Pascal）可是正好相反啊。OO出现之前的过程语言时代也应该被看作是一种完全不同的活动吗？

    我不这样认为。事实上，我觉得我们现在所说的面向对象技术很大一部分是在过程编程技术成熟的基础上产生的。从根本上讲，正是在过程语言的最佳实践得到了良好的运用之后，才引出了面向对象语言中最基本的概念。

    事实上，我觉得面向对象作为一种编程方式早在面向对象语言出现之前就开始被人们使用了。现在，我只需说“面向对象范式与过程语言范式共享很多思想”就够了。假定我们都同意这个观点，那么我还要将结构化编程的时代包括进来，作为软件制作历史的一部分。（有关这方面的讨论请参阅第4章。）这样，我就可以说软件制作的历史大约为30～35年。

    好了，下面来谈另一个问题。

软件开发是一种什么样的活动

    它是一种职业，一门手艺，一个专业，还有别的吗？有人可能说它是一门艺术或科学，有人可能说它是工程，还有人会说它是演绎逻辑的一个分支。我相信这个问题的价值主要并不在于找到答案，而在于通过这个问题引发其他问题。

    人们有很多词语来形容他们赖以谋生并为身边的世界做出贡献的事情，例如工作、劳动、行业、手艺、副业、技能、追求、技艺、职业、专业，等等。不同的人用不同的方式来使用这些词语，使用时也伴随着一些被人们广泛接受的暗示、区别、期望和假设。

    就拿培训来说吧。大多数人都会把“需要大量培训”与专业或行业的概念联系到一起，而不是一般的劳动或工作①。这并不是说所有工作都很简单，但进入某个专业或行业肯定有非常严格的要求，不会像随便找一份工作一样。

    另一个区别是许可与监督。医生、律师、会计师、承包商等都需要国家发给从业许可，以确保他们能够胜任，并确保他们的技能和培训已达到一个最低标准。通常，这是因为如果他们不胜任的话，会造成严重的损害。当然，这也暗示着存在一套公认的标准，是这些专业人员可以掌握的，而且这些标准都是正确的。

    此外，由于他们需要达到这些严格的要求和标准，因此专业人员（和工匠）组成了各种支持性组织（协会、联盟和专业组织），为专业人员提供支持并帮助他们获得成功。这些组织也提供了一个积累集体智慧和知识的集中场所，从而保持行业的持续发展，并让知识代代相传。

    当一个人从事复杂（有时甚至关乎生命）的工作时，有这种支持是非常有利的。它可以让专业人员知道自己在一些重要方面是否符合标准，以及如果不符合标准该怎么办。对于那些接受专业人员服务的人来说，好处也是很明显的。比如，在我看来，我的医生知道自己在做什么，这是很重要的，而且有其他人（最好不是我）能证实他是否胜任，这也同样重要。

    此外，专业还倾向于发展出专门的、高度专业的语言。例如，医生把阑尾切除手术叫做“appendectomy”，而把结肠切除手术叫做“colostomy”。为什么一个后缀用“-ectomy”而另一个后缀用“-ostomy”呢？我不知道，但医生们肯定知道，而且我打赌这个区别对于医生们来说很重要。而我们所知道的只不过是我们的某个器官被切除了。

    因此，我在这里有点武断地决定用“专业”这个词来表示一个需要大量、长期培训的职业，它拥有专门的语言，用来描述专业人员所做的事情，并使得他们可以高度精确地互相交流，而且专业通常还有一种为从业人员提供支持的专业组织。专业的背后有大量的传统、明确的实践和支持团体，以及供所有成员共享的集体智慧。专业提供了对活动和想法的同行评审，还提供了许可或认证过程，这通常作为专业学科的一部分，以便给予专业人员信心，并使得那些接受他们服务的人感到放心。

    而且，如果你想成为一名医生、律师或家具制作大师，你需要遵循一个明确定义的路径。当社会需要更多这样的人时，我们知道培养他们的过程，也知道如何指导年轻人为某个专业生涯做准备。

    那么软件开发属于哪一类呢？

    软件开发当然很复杂，需要大量的培训和经验才能做好。并不是每个人都能够从事软件开发，这并非因为它超过了某些人的能力，而是因为并非每个人都想从事或长期坚持从事这个职业。它需要一定的特质，还需要爱好技术并热衷于解决问题，这些特点不是每个人都具备的。此外，随着时间的推移，人们成立了许多支持性的组织，软件开发人员在这里寻求共享他们的知识和工作方法。整个开源运动就是一个例子，它是由软件开发人员共同管理的，例如Java用户组和.Net程序员学习小组。开发人员几乎都是用自己的力量来支持这些工作，因为他们认为这样的组织是有价值的。

    因此，我可以说软件开发从本质上说是一项专业活动。无论我们是否已经把它当作一项专业，我们都应该这样做。我们暂时不考虑它是否应该被纳入政府管理这个问题，因为这里的重点是弄清楚软件开发作为一个专业应该提供的东西，这些东西使得软件开发人员直接受益，并有助于提高他们所开发软件的质量。

    如果你能同意上述观点，那么请接着往下读。

    我们创建软件的时间并不长。而其他大多数专业和工艺都有数百年乃至数千年的历史，并且长时间以来形成了支持这些专业的基础。

    例如，想象一下当医学只有35年历史时是什么样子的。我能想到的是巫师把水蛭吸附到人身上，不断地摇动拨浪鼓，用放血的手段实现治疗的目的。有趣的是，那时的医学确实做到了一定程度的成功。事实证明失血可以减轻发烧，尽管这不是一个非常好的退热方法（有时甚至会使人因失血过多而死亡）。即便在今天，医生的治疗效果在很大程度上也与病人对医学的信任、病人认为接受的治疗会让他变好的信心密切相关。

    因此，巫医有时也能看好病，只是这不常发生。治疗过程也并非绝对地可靠和可预测，这是不是听上去很熟悉？

    此外，在软件开发的35年历史中，在计算能力以及商业和日常生活与软件的关系等方面发生了多大的变化？人们现在的身体与医学刚刚出现时的身体基本是完全一样的，因此医生可以大量依靠过去的做法和发现，同时学习新技术，把专业水平推向前进。我们却没有这份奢侈，现在的计算机与短短几年前的计算机就完全不同了。例如，计算机的速度已经快了几个数量级。而且，当我刚开始编写软件时，像磁盘存储空间和内存这样的关键资源不仅非常昂贵，而且十分有限（那时根本没有100GB的硬盘，你有钱也买不到）。如果我们后退足够长的时间（实际上也没有多久），能够与计算机打交道的人只有那些受过训练的、技能娴熟的操作员。是的，这些都是很大的、渐进式的变革，但变化是一个基本现实，甚至一个人的整个职业生涯都在经历变化。

    因此，有多大可能把“制作软件”这件事完全做对呢？我认为可能性非常小。事实上，考虑到软件开发可能仍处在“水蛭加拨浪鼓疗法”的初级阶段（至少在一定程度上是这样的），因此我们能做开发就已经很不错了。

    换言之，我想说的是软件应该被当作一个专业活动来做，但事实上人们并没有这样做，至少专业化程度不高。

软件开发缺少了什么

    让我们把软件开发与其他专业做一下对比。

    专业语言。在软件开发中，语言总是倾向于实施细节的。像“回路”、“转换”、“中止”和“异常”这样的词虽然是专用的，但却都是针对很低层次的。木匠大工在吩咐小工如何做一个榫卯结构时，不会用角度和英寸来说明。术语本身就说明了所有规格，也说明了为什么要把东西做成这样或那样，你将会遇到什么难处和机会，以及选择这条路之后会得到或失去什么。这种高级的专业语言帮助专业人员做出更好的决策，而且常常是集体决策。这里我要发表的看法之一是设计模式运动就是为软件开发工作增加高级专业语言的一种尝试，目的是提高我们的专业水平。这倒并不一定是这项运动背后的目的，但事实证明它在这方面确实做出了巨大的贡献，或许是无意的。我认为这也部分地解释了模式和模式书籍流行的原因。我想很多人都认识到了我们的工作中、我们的思考和交流方式中缺少什么东西。能够倾听这种内心的直觉，说明我们在专业化方面正在走向成熟。

    一个进入专业的明确路径。如果有人问你“要想成为软件开发人员，应该做什么”，你将如何回答他们？上大学？阅读几本书籍？通过某厂商的认证？还是先找一份工作滥竽充数，直到你能够做软件？如果你想成为一名成功的民事律师，那么我至少可以大体上告诉你应该怎样做。首先读大学（法学院），然后在一个法律机构实习并通过律师资格考试，成为一名助理律师，最后再朝着一名正式合伙律师努力。你想成为一名刑事律师吗？有类似但不同的步骤，但这些路线都是明确定义的。我的一位同事Adam Milligan这样说：“我们有医学院、法学院，但开发学院在哪里？”没有开发学院。医院聘用住院实习医生，以便让经验丰富的医生来培训这些新人。医院懂得，如果想培养新的医生，提高他们的医术，以便确保病人健康和幸福，就必须这样做。软件开发尚未采用这种做法，但实际上也需要这么做。

    同行评议。医生和律师都有同行评议的期刊及其他为专业人员提供支持的机制。这些机制使得专业人员可以把专业推向前进，并且可以对新的实践和程序进行现实核查。

    软件开发中也有类似的资源，但都非常杂乱无章，而且没有得到良好的组织。你可以在Google上搜索一个问题，在Usenet上寻求答案，但得到的结果却十分凌乱。前面提到的很多用户组和学习小组作为“草根”一族正在进行着建立软件业同行评议的基本尝试。博客的广泛使用也同样如此，人们通过博客来分享软件的思想和智慧，人们做了很多了不起的尝试，但都是混乱无序的。

    标准和实践。医生有一些特定的操作，遵循这些操作，医生们可以保证一定程度的成功，至少可以确保不失败。例如，医生知道清洁是非常重要的。他们对器械进行消毒，并且在为病人治疗前仔细地洗手。

    但医生们也并非从一开始就知道这一点。直到19世纪的中后期，外科医生在为病人做手术之前还都是嫌麻烦，不愿意去洗手或清洗器械，结果，他们治疗的失败率（病人的死亡率）就比正常应有的失败率高得多。匈牙利裔医生Ignaz Semmelweis 1860年在维也纳的一个接生所工作时提出，有一些微小的、肉眼看不到的东西会使人们患病，因此医生应该在为病人治疗之前彻底洗手并清洗医疗器械。

    当时，他提出这种理论倒不如去指责鬼魂或幽灵来得好。他遭到嘲笑，先后三次险些被撤销从医许可，最终不得不故意使自己感染，以证明他的观点。在Semmelweis医生去世之后，细菌致病的理论才得以发展起来，现在，他被认为是消毒理论和预防感染的先驱①。现在，所有医生都知道这一点。他们不必再去重新发现医疗程序中的这个基本事实。他们甚至在非正式地会见一位新病人时也会洗手。

    在软件开发中，人们有一种传统的倾向，那就是期望每个开发人员自己去发现这样的事情，犯所有人已经犯过的同样错误，重新解决相同的问题，总之一切都要自己从头干。这实际上是“牛仔编码者”文化的一部分，即开发人员总是争强好胜，而不是互相支持②。在很多组织中这个问题愈加严重，因为他们倾向于把高级开发人员调往管理职位，导致那些初级开发人员不易从他们那里学到东西。看起来人们并没有认识到“会念经的和尚”的重要价值。

    问题并不仅仅在于我们知道什么，或不知道什么。我们必须学会分辨事情的轻重缓急——哪些事情必须现在就引起重视，哪些事情可以安全地忽略或过后再考虑。

    专业就像一个活的有机体。医学已经存在数千年了，但没有哪位医生能活这么久。今天的医生可以从医学这个有机体得到支持，他们可以从Simmelweis医生这样的先驱者们曾经的艰苦工作和牺牲中获益，尽管Simmelweis医生已经去世很久了。

谁说了算

    一般来说，一个人在去看医生时不会说：“你知道，医生，我想我需要做一个阑尾切除术。”你应该告诉医生你的症状，然后由医生来建议适当的治疗方法。

    在软件开发中，我们没有把自己当作专业人员，因此客户也没有把我们当作专业人员。项目的干系人往往设置时限，强行规定开发过程，并且干涉项目的进行。

    如果软件开发是一个专业的话，这些就都将由我们自己决定，或者至少在很大程度上受我们的影响。我们将负责制定这些决策，而且可以非常肯定地告诉客户他们会得到什么，以及何时得到。但是，目前的情形就像是一个人到医生那里做手术，告诉医生：“你有一个小时的时间，我要赶在11点前去打高尔夫球。”

    这需要思想上的转变，做出改变的不仅是我们自己，还有客户。这需要建立信任，改变客户与开发人员之间关系的基本本质，并且通过提高成功率来证明我们的价值。

    虽然这是一个艰难的过程，但它必须发生。

    我相信软件开发不仅仅应该被当作一个专业来从事，而且在21世纪的今天，它应该被当成一个最重要的专业来对待。

    原因何在？

    所有专业都要使用软件，因此会受到软件成本和质量的极大影响。当你坐飞机旅行时，实际上是坐在软件上飞行，而且对软件的依赖性越来越强。当医生扫描病人的腹部，并盯着超声波机器的屏幕看是否有肿瘤时，她需要依靠软件来判断如何为病人做诊断。当个人身份信息被盗用时，也是由于别人的软件在某个地方泄露了你的信息。

    这至少在某种程度上又回到了规章和认证的问题上。有关我们这个专业应该适用什么样的规章和认证，我尚未形成一个明确的观点，但我十分关心这个问题。在未来的若干年中，随着软件日益渗透到普通人日常生活的各个方面，软件的失败将越来越成为社会关心的一个问题。如果我们继续使人们暴露在身份盗用、医疗和运输事故、病毒、Y2K（或夏时制）等类型的bug的风险之下，那么最终人们会另去寻找解决问题的办法。

当然，他们将求助于政府。我并不想太强调这点，也不想成为一个杞人忧天者，但坦白地讲，如果美国众议院要来为专业软件开发设定标准，我想我们不会有什么好果子吃的。我们必须自己做这件事，而且我认为最好现在就开始做。有很多事情要做，我并不是强调所有事情都要在这里做完（这应该是一个全社会都参与的草根活动）。但我希望本书能够澄清一些关键问题，并起到抛砖引玉的作用。

独特性

    让我们来澄清这样一件事：我并不是说软件开发就像医学、法律或任何其他专业一样。医学与法律也不一样。医生也不是木匠。

    专业具有独一无二性。它们都已发展出独特的、非常符合本身性质的流程。这些流程源自对专业性质的基本理解，而且是由自己专业的群体经过长时间逐步建立起来的。医学之所以是现在这个样子，是由于医学专业人员在长期的专业历史中所累积的经验而形成的。

    软件开发实践中的一部分问题在于它在很大程度上是基于一个有缺陷的原则建立起来的，即它看上去不像是专业的软件开发。这就是接下来的两章要讨论的问题。