1、第一章 欢迎进入软件创建世界 1 第一章第一章第一章第一章 欢迎进入软件创建世界欢迎进入软件创建世界欢迎进入软件创建世界欢迎进入软件创建世界 目录目录目录目录 1.1 什么是软件创建（Software Construction）1.2 软件创建的重要性 1.3 小结 相关章节相关章节相关章节相关章节 本书适合什么人阅读：见前言 阅读本书的益处：见前言 为什么要写这本书：见前言 大家都知道“Construction”这个词在一般情况下的意思是“建筑”。建筑工人盖房子、建学校、造摩天大楼等时所进行的工作都是建筑。当你小的时候，你用积木进行“建筑工作”。因此“Construction”指的是建造某个
2、东西的过程。这个过程可能包括：计划、设计、检验等方面的某些工作，但是，它主要是指在这其中的创造性工作。1 1 1 1.1 1 1 1 什么是软件创建什么是软件创建什么是软件创建什么是软件创建 开发计算机软件是一项非常复杂的工作，在过去的十五年中，研究者们指出了这项工作所包括的主要方面，包括：问题定义 需求分析 实现计划 总体设计 详细设计 创建即实现 系统综合 单元测试 系统测试 校正性的维护 功能强化 如果你以前从事过一些不太正规的研制工作，你可能以为列出的这个表有些太详细了。而如果你从事过一些正式的项目，你就会认为这个表非常准确。在正规性与随意性之间达到平衡是非常困难的这会在以后章节中讨论
3、。如果你是自学编程员或是主要从事非正规研制工作，你很可能还没有意识到这些在生产软件中所需要的工作步骤。在潜意识中，你把这些工作统统称为编程。在非正式项目中，当你在考虑设计软件时，你所想到的主要活动可能就是研究者们所指的“创建”工作。关于“创建”的直觉概念是非常准确的，但它往往缺乏正确观点。把创建活动放到与其相第一章 欢迎进入软件创建世界 2 关活动的背景中，有助于我们在适当重视其它非创建工作的同时，把主要精力放在正确的任务上。图 1-1 中给出了创建活动在典型软件生存周期循环中的地位和包括的范围。正如图中所指出的，创建活动主要指编码和调试过程，但也包括详细设计和测试中的某些工作。假如这是本关于
4、软件开发所有方面的书，它应该涉及到开发过程所有方面并给予同等重视。但因为这是一本关于创建技术的手册，所以我们只重点论述创建活动及相关主题。如果把这本书比喻成一只狗，那么它将用鼻子轻擦创建活动，尾巴扫过设计与测试，而同时向其它开发活动汪汪叫。创建活动有时被称作“实现”，它有时被叫作“编码和调试”，有时也称之为“编程”。“编码”实在不是一个很好的叫法，因为它隐含着把已经设计好的程序机械地翻译成机器语言的过程；创建则无此含义，它指的是在上述过程中的创造性和决策性活动，在本书中，将交替使用“实现”、“编程”和“创建”。图 ll 软件生存周期中软件开发过程的平面图 在图 11 中，给出了软件开发过程的平
5、面图示，而在图 12 中，则给了它的立体图示。图 11 和图 l2 是创建活动的总体图示，但是，什么是它的细节呢？下面是创建活动中所包含的一些特定任务。验证基础工作已经完成，可以进行创建工作 设计和编写子程序与模块 第一章 欢迎进入软件创建世界 3 创立数据类型并命名变量 选择控制结构并组织语句块 找出并修正错误 评审其它小组的细节设计和代码，同时接受其它小组评审 通过仔细地格式化和征集意见改进编码 对分别完成的软件单元进行综合 调整编码使其更小、更快 图 12 本书主要详细论述详细设计、编码、调试和单元测试（所占比例如图示）要想更详尽地了解创建活动，请参阅目录中每一章的标题。创建活动包括如此
6、众多的工作，人们可能会禁不住要问：“哪些是创建活动呢？”。一般认为，非创建活动包括：管理活动、需求分析、软件总体设计、用户交互界面设计、系统测试、维护工作等。这其中每项工作都与创建工作一样，会直接影响到项目的最终成败（那些需要两个人以上合作至少一星期项目的成败）。关于这其中每一项活动都有很不错的论著，在本书每一章后都列出这些书的书名。1 1 1 1.2 2 2 2 软件创建的重要性软件创建的重要性软件创建的重要性软件创建的重要性 正如我们所知，改进软件质量、提高软件生产率是非常重要的。当今世界许多激动人心的工程计划中，软件都被广泛地应用：太空飞行、航空、医学与生命保障科学、电影特技、金融信息的
7、快速处理、科学研究等，这仅是其中的几个例子。如果读者您也认为软件开发是重要的，那么您就会问，为什么创建活动是重要的？原因如下：创建活动是开发软件的重要组成部分。创建活动是开发软件的重要组成部分。创建活动是开发软件的重要组成部分。创建活动是开发软件的重要组成部分。随项目规模不同，创建活动在整个开发活动中所占时间为 3080之间，在任何计划中占有如此大时间比例的活动必然会影响计划的成败，这是不言而喻的。创建活动在软件开发中处于枢纽地位。创建活动在软件开发中处于枢纽地位。创建活动在软件开发中处于枢纽地位。创建活动在软件开发中处于枢纽地位。分析和设计是创建活动的基础工作，对系统进行测试以证实创建活动是
8、正确的则是其后续工作，因而创建活动是软件开发的核心工作。把主要精力集中于创建活动，可以极大地提高程序员的生产效享。把主要精力集中于创建活动，可以极大地提高程序员的生产效享。把主要精力集中于创建活动，可以极大地提高程序员的生产效享。把主要精力集中于创建活动，可以极大地提高程序员的生产效享。由 Sackman、Erikson 和 第一章 欢迎进入软件创建世界 4 Grant 在 1968 年进行的实验表明，每个程序员的效率系数的变化范围为 1020，这一结果随后又被其它几个实验所证实。最优秀程序员与普通程序员的巨大差异表明，普通程序员提高效率的潜力是非常大的。创建活动的产品，源代码，往往是软件的唯
9、一精确描述。创建活动的产品，源代码，往往是软件的唯一精确描述。创建活动的产品，源代码，往往是软件的唯一精确描述。创建活动的产品，源代码，往往是软件的唯一精确描述。在许多项目中，程序员可得到的唯一文件便是代码本身。需求说明和设计文档可能会过时，但源代码却总是最新的。因此，源代码必须具有最好的质量。一个软件成功与否的关键，就在于是否不断运用技术来改进源代码。而这些技术恰恰是在创建阶段，才能得以最有效的应用。创建活动是唯创建活动是唯创建活动是唯创建活动是唯一项必不可少的工作。一项必不可少的工作。一项必不可少的工作。一项必不可少的工作。理论上一个软件项目要经过精心的需求分析和总体设计，然后再进行创建，
10、接着对其进行彻底的、严格的系统测试。然而，实际工作中的软件项目，往往越过前两个阶段而直接进行创建活动，最后，由于有太多的错误要修改，系统测试又被弃之路旁。但是，不管一个项目的计划多么疏漏而又如何匆忙，创建活动都是必不可少的。无论怎样精简，改进创建活动都是改进软件开发工作的方法。l.3 l.3 l.3 l.3 小小小小 结结结结 创建活动是总体设计和系统测试之间承上启下的工作。创建活动主要包括：详细设计、编码、调试和单元测试。关于创建活动的其它称谓有：实现、编程等。创建活动质量对软件质量有潜在影响。在最后的分析中，对创建活动理解的好坏，决定了一个程序员素质的高低，这将在本书其余部分论述。第二章
11、利用隐喻对编程进行更深刻的理解 5 第二章第二章第二章第二章 利用隐喻对编程进行更深刻的理解利用隐喻对编程进行更深刻的理解利用隐喻对编程进行更深刻的理解利用隐喻对编程进行更深刻的理解 目录目录目录目录 2.1 隐喻的重要性 2.2 如何使用软件隐喻（Software MetaPhors）2.3 通常的软件隐喻 2.4 小结 相关章节相关章节相关章节相关章节 设计中的启发：“设计是一个启发过程”见 7.5 节 计算机科学的语言可能是所有科学领域中最丰富的。想象一下。你走进一间干净整洁、温度严格控制在 68的房间，在这里，你将会找到病毒、蠕虫、臭虫、炸弹、崩溃、火焰、扭曲的变形者、特洛伊木马和致命
12、错误，在其它领域中，你会遇到这种情况吗？这些形象的隐喻描述了特定的软件现象。同样形象的隐喻描述了更为广泛的现象，你可以利用它们来加深你对软件开发的理解。本书其余部分与本章关于隐喻的论述无关，如果你想了解实质问题可以跳过这一章。但你要想对软件开发有更清楚的理解，请阅读这一章。2.1 2.1 2.1 2.1 隐喻的重要性隐喻的重要性隐喻的重要性隐喻的重要性 重大发现往往是从类比中产生的。通过把一个你所陌生的事物与你所熟知的事物比较，你会对它有进一步的认识，从而形成你对它的独到的深刻理解，这种隐喻方法被称之为“模型化”。在科学发展史上，充满了利用类比而产生的发现。化学家 Kekle 梦见一条蛇咬住了
13、自己的尾巴，醒来后，他由此联想到苯的结构，提出了苯是环形分子的假说，这一假说在 1966 年被 Barbour用实验所证实。分子运动论是在“保龄球”模型上建立起来的。在这里，分子被假想为具有质量并且与保龄球一样相互之间进行完全弹性碰撞的小球，并且在此基础上，又产生了许多有用的模型。光的波动理论是在与声音类比的基础上产生的。光与声都具有振幅（亮度与音量），频率（颜色与音调）和其它类似性质。这种类比是如此有效，以致于科学家们花费了大量时间来寻找像空气传播声音一样传播光的物质“以太”，但他们从来也没能找到。有时如此有效的类比这次却导出了错误结果。通常，模型的力量在于它能提供生动形象的概念而易被人整个
14、接受。并提供特性、联系和附加的疑问，有时模型会提出令人困惑的问题，这时往往是由于模型被误解了，那些建筑“以太”的科学家们，就是因为误解了模型。正如你所预料的，有些模型比其它的要好。好的模型要简单、与其它模型关联密切、能解释 第二章 利用隐喻对编程进行更深刻的理解 6 大部分实验事实和观测现象。比如一个悬在铁链上来回晃动的大石头。在 Galileo 之前，Aristotelian 看到它时想到的是重物必然要从高处落下来停在低处，他认为石头是在克服阻力下落，而当 Galileo 看到同一现象时，他认为自己看到了一个单摆，他认为石头是在不断地重复同一运动。这两个模型所提供的信息是截然不同的。Aris
15、totelian 认为石头是在下落，因而他关心的是石头的重量、升起的高度及停下所需的时间。而 Galileo 从单摆模型出发，他关心的是石头的重量、铁链的半径、石头的角位移及石头每摆一次所需要的时间。Galileo 之所以能发现单摆定律，就是因为他的模型与 Aristotelian 不同，从而导致他们提出了不同的问题。隐喻对加深软件理解所做出的贡献，与它对其它领域所做出的贡献一样大。1973 年，在图灵奖颁奖演说中，Charles Bachman 叙述了从地心说向日心说转移的过程。Ptolemy 的地心说统治了近 1400 年。直到 1543 年，Copernicus 提出了日心说，这一思想模
16、型的转变导致了一系列新星的发现，把月亮定义为卫星而不是行星，也改变了人类对自身在宇宙中地位的理解。Bachman 把天文学中从地心说向日心说的转变，与 70 年代前期在计算机编程中的变化作了个对比。在当时，数据处理正从以计算机为中心向以数据库为中心进行转变。Bachman 指出，在旧的处理模式中，数据被当成是一个连续流过计算机的卡片流（以计算机为中心）；而在新的模式中，数据好比是一个水池，而计算机则偶尔涉足其中（以数据库为中心）。今天，很难想象谁会认为太阳绕着地球转；也同样难以想象推会把数据当成流过计算机的卡片流。在这两个例子中，旧的理论一旦被抛弃，很难想象有谁会再把它捡起来。具有讽刺意味的是
17、，旧理论的相信者认为新理论荒唐可笑，就像我们今天看旧理论一样。当日心说出现之后，地心说便成了那些相信它的天文学家的阻碍。同样，计算机中心模式也已经成了那些相信它的计算机科学家的阻碍，因为我们现在已经有了数据库中心模式。如果一旦看了新的模型，我们便说：“哦，当然正确的模型更有用，其余的都是错误的”，那只会降低模型的作用。因为这太偏激了。科学史并不是由一系列从“错误”模型到“正确”模型开关组成的，而是逐渐由“坏的”模型变为“较好”的模型，从包含面较窄到包含面较宽，从覆盖领域较少到覆盖领域较多。事实上，很多被较好模型替代的旧模型仍然在发挥作用。例如，工程师们仍然在用牛顿力学进行工程计算，虽然它已经被
18、相对论力学所取代。软件科学是一门比其它学科年轻得多的学科，还很不成熟，远未形成一套标准的模型。所以，现在拥有的是大量相互矛盾的模型。这其中有些很好，有些则很差。因此，对这些模型理解得好坏，便决定了你对软件开发理解的好坏。2.22.22.22.2 如何使用软件隐喻如何使用软件隐喻如何使用软件隐喻如何使用软件隐喻 软件隐喻更像是一束搜索灯光，而不是一张地图，它并不会告诉你到哪里去寻找答案；它 只给你以启发，教你如何寻找答案，而不是像数学算法一样硬性规定出到哪里找出答案。一个公式是一套完整建立的、进行某一些任务的规则。它的结果是可以预测的、确定的，并不取决于运气。公式会告诉你直接从 A 点走到 B
19、点，中间不准绕路，不准随意顺便访问 C、D、E 或 F 点，也不准停下来闻一下玫瑰花香或者喝杯咖啡什么的，一切必须按规定来。启发是一种帮助你寻求答案的技术。它的结果往往和运气有关，因为它只告诉你如何去 第二章 利用隐喻对编程进行更深刻的理解 7 找，而并未告诉你应该找到些什么。它不会告诉你怎样直接从点 A 到点 B甚至很可能它根本就不知道点 A 和点 B 在哪里。事实上，可以认为启发是一个穿着小丑儿外套的公式。它往往不可预测，更富有趣味，不会保证一定会发生或不会发生什么。比如，开车去某人家的公式是这样的：沿 167 号公路向南到 Sumner，从 Bonney 湖出口向山上开 2.4 英里，借
20、助加油站的灯光向左拐，在第一个右转弯处向右转，再拐入通向褐色房子的公路，寻找的门牌号是北大街 714 号。以下则是一个如何找到我们房屋的启发：找到我们寄给你的最后一封信，开车到回信地址所说的小镇，到了镇上后随便问哪个人我们住哪儿，别担心，镇上的人都认识我们。如果你谁也遇不到的话，就打电话找我们。公式和启发之间的区别是微妙的，这两个例子或许会说明一些问题。从本书的角度来看，它们之间的主要区别是：它们与答案之间的直接程度。公式给予直接指令；而启发则告诉你该怎样找到这些指令，或者至少告诉你到哪里寻找它们。如果有一套指令告诉你该如何解决程序中的问题，这当然会使编程变得很容易，而且结果也可以预测了。但是
21、编程科学目前还没有那样发达，也许永远也不会。编程中最富于挑战性的问题便是将问题概念化，编程中许多错误往往都是概念性错误，因为每个程序在概念上都是独特的，所以创立一套可以指导每一个问题的规则是非常困难，甚至是不可能的。这样，从总体上知道该如何解决问题，便几乎和知道某一特定问题的答案一样重要了。你是怎样使用软件隐喻的呢？应该用它来帮助你获得关于编程过程的内在理解，利用它们来帮助你考虑编程活动，想象解决问题的更好办法。你不要一看到某一行代码就说这与这一章所使用的某个隐喻相矛盾。随着时间推移，在编程过程当中使用隐喻的程序员肯定比不使用这一方法的人编写代码更快更好。2 2 2 2.3 3 3 3 通常的
22、软件隐喻通常的软件隐喻通常的软件隐喻通常的软件隐喻 随着软件的发展，隐喻越来越多，已经到了使人迷惑的地步，Fred Brooks 说写软件就像耕种、猎狼或者在一个沥青矿坑中淹死一只恐龙。Paul Heekel 说这就像电影白雪公主与七个小矮人。David Gries 说这是科学，Donald Knuth 则说这是门艺术，Watts HamPhrey 则说这是一个过程，Peter Freeman 说这是个系统，Harlan Mills 认为这就像解数学题、做外科手术、或者是宰一条狗，Mark Spinrad 和 Curt Abraham 说这更像是开发西部、在冰水中洗澡或者围着营火吃豆子。2 2
23、 2 2.3 3 3 3.l l l l 软件书写：写代码（软件书写：写代码（软件书写：写代码（软件书写：写代码（Writing Code）开发软件最原始的隐喻出自“写代码”一词。这个写的隐喻说明开发一个程序就像随便写封信，你准备好纸、笔和墨水，坐下从头写到尾就算完成了。这不需要任何正式计划，你只是把你要说的都写出来。许多想法都源于写隐喻。Jon Beitle 说，你应该准备好一杯白兰地，一支上等雪茄，与你喜欢的猎狗一同坐在火边，像一个优秀小说家一样享受一次“自由编程”。Brian 和 Kernighan 把写隐喻风格的书称为 风格要素（The Elements of Style）之后，把他们
24、编程风格的书称作 编程风格要素（The Elements of Programming Style），程序员们则经常谈论程序的“可读性”。第二章 利用隐喻对编程进行更深刻的理解 8 在一些小问题中，写代码隐喻可以充分描述它们。但是对于其余的问题，它就力不从心了，它不可能全面彻底地描述软件开发过程。写往往是一种个人活动，而软件开发往往需要许多人分担各种不同的责任。当你写完一封信时，你把它装进信封并把它寄出去后，你就再也不能改变它的内容了，无论从哪个角度说，这项工作都已经完成了。软件的内容是很容易改变的却很难彻底完成。几乎有50的软件开发工作量是在软件最初发行之后才进行的（Lientz和Swans
25、on，1980）。编写软件，主要工作量集中在初始阶段。在软件创建中，把精力集中于初始阶段往往不如在初始工作完成后，再集中精力进行代码的重新调整工作。简而言之，写隐喻往往把软件工作表示成是一项过于简单而刻板的工作。不幸的是，写隐喻已经通过我们这个星球上最流行的软件书Fred Brooks 的The Mythical Man Month而变得永存了。Brooks 说，“扔掉一个计划，又有什么呢？”这使得我们联想到一大堆被扔进废纸篓的手稿。当你写封家常信问候你叔叔时，准备扔掉一封信是可能的，这也可能是 Brooks1975 年写那本书时，当时软件工程的水平。但是，到了九十年代，再把写隐喻解释为准备扔
26、掉一封信时，恐怕是不合时宜的。现在，开发一个主要系统的投资已经相当于建一幢十层办公楼或造一艘远洋客轮的费用了。我们应该在第一次调试时就完成它，或者在它们成本最低时试几次运气，其它几个隐喻较好地解决了说明达到这一目的的方法问题。2 2 2 2.3 3 3 3.2 2 2 2 软件播种：生成系统（软件播种：生成系统（软件播种：生成系统（软件播种：生成系统（Growing a System）与刻板的写隐喻相反，一些软件开发者认为你应该把创建软件当作播种或培植庄稼。你设计一小部分，编码一小部分，测试一小部分，然后在某个时候把它加到系统上，通过小步走，你减小了每次可能遇到的错误。有时，一项先进的技术可能
27、是通过拙劣的隐喻来表达的。在这种情况下，应努力保留这项技术并换一个隐喻来表达它。在这里增量技术是先进的，但是种庄稼的比喻则是十分拙劣的。一次干一点儿的想法可能和植物生长有某种类似之处，但是耕种类比实在太牵强，而且也令人感到陌生，因而也就很快被后面的隐喻所取代了。很难把耕种隐喻推广到每次做一点儿这一简单想法之外。如果你来用耕种隐喻，你就会发现自己在谈论给系统计划施肥，减少详细设计，通过有效地田间管理提高编码产量，最后收获编码。你也会谈论进行轮作，用种小麦代替大麦，让土地休息一年以提高土壤中的养分。软件种植隐喻的弱点是你对于软件开发失去了直接控制。你在春天播种代码，最后在秋天收获一大堆代码。2 2
28、 2 2.3 3 3 3.3 3 3 3 软件珍珠培植法：系统积累（软件珍珠培植法：系统积累（软件珍珠培植法：系统积累（软件珍珠培植法：系统积累（System Accretion）有时候，人们在谈论种植软件而事实上他们指的是软件积累。这两个隐喻是密切联系的，但是软件积累更深刻一些。“积累”这个词，含有通过外加或吸收，缓慢生长的意思，就像河蚌逐渐分泌酸钙形成珍珠一样。在地质学上，水中悬浮物逐渐沉积形成陆地的过程也与此相似。这并不是说你要从水中悬浮物里沉积出代码来；这只意味着你应该学会每次向你的系统中加一点儿东西。另外一个与积累密切相联的词是增量。增量设计、构造、测试是软件开发的最强有力工具之一。
29、“增量”一词在设计者心目中还远未达到“结构化”或“面向对象设计”等的地位，所以迄今为止也没有一本关于这方面的论述，这实在是令人遗憾的，因为这种书中所收集的技术将具有极大的潜力。第二章 利用隐喻对编程进行更深刻的理解 9 在增量开发中，你首先设计系统可以运行的最简单版本。它甚至可以不接受实际数据输入，或者对数据进行处理。它也可以不产生输出，只需要成为一个坚实的骨架结构，以便能承受将要在它之上发展的真实系统。它可以调用任何一个实现预定功能而设立的伪子程序。就像河蚌刚开始产生珍珠的核一粒沙子。当你搭好骨架后，逐渐地往上添加肌肉和皮肤。你把每一个伪子程序变成真正的子程序。此时你不必再假设产生结果了，你
30、可以随意访问一个代码来产生结果。也不必使其假设接收输入，你可以用同样的方法让它接收输入。你每次加入一点儿代码直到你最终完成它。这种方法的发展是令人印象非常深刻的。Fred Brooks，在 1975 年时还认为：“应做好建造一个扔掉一个的准备”，在 1987 年时，却说在过去的岁月里，还没有一样东西像增量概念这样如此深刻地改变了他自己的实践或效率。增量隐喻的力量在于：作为一个隐喻，它并没有过分作出许诺，它不像耕种隐喻那样容易被错误延伸。河蚌育珍珠的联想对理解增量发展法或积累法有很大帮助。2 2 2 2.3 3 3 3.4 4 4 4 软件创建：建造软件（软件创建：建造软件（软件创建：建造软件（
31、软件创建：建造软件（building software）“建造”一词的想象比“写”或者“种植软件的想象更为贴切，它与“增量”软件的想法是基本一致的。建造隐喻暗示了许多诸如计划、准备、执行等工作阶段。如果你仔细研究这个隐喻，你还会发现它还暗示着其它许多东西。建造一个四英尺高的塔需要一双稳健的手、一个平台和十个完好的啤酒罐。而建造一个四百英尺高的塔却决不仅仅是需要一千个啤酒罐就够了，它还需要一种完全不同的计划和创建方法。如果你想建一个简单的建筑物，比如说一个狗舍，你买来了木板和钉子，到下午的时候，你已经给你的爱犬造好了一幢新房子，假设你忘了修一个门，不过这没关系，你可以补救一下或推倒一节重新开始。
32、你所浪费的不过是一个下午的时间罢了。这与小型软件的发展失败非常类似。如果你有 25 行代码设计错了。那你重新再来一遍好了，你不会因此浪费许多的。然而如果你是在造一幢房子，那修建的过程就要复杂些了，而拙劣设计的后果也严重得多。首先，你必须决定造一幢什么样的房子，这就像软件开发中的问题定义。然后，你与建筑师必须搞出一个你们都同意的总体方案，这和软件的总体设计是一样的。接着，你又画出细节蓝图并找来一位承包商，这相当于软件中的详细设计。下面的工作是选好房址、打地基、建造起房屋的框架、建好墙壁并加上屋顶、用千斤锤检查墙壁是否垂直，这同软件创建基本差不多。当房屋的绝大部分工作已经完成时，你请来园艺师和装修
33、师，以便使你的房间和空地得到最好的利用，这可以与软件优化相类似。在整个过程中，会有各种监督人员来检查房址、地基、框架、供电系统和其它东西，这也可以与软件开发中的评审和鉴定相类似。较大的规模和复杂性往往意味着可以产生较大的成果。在修房子的时候，材料可能比较贵，但更大的花费是劳动力。拆掉一面墙并把它移到六英尺之外是很昂贵的，但并不是因为你浪费了许多钉子，而是因为你需要付出劳动。你应该尽可能精心设计，以避免那些本可避免的错误，以降低成本。在开发软件过程中，材料更便宜，然而劳动力成本却更高。改变一个报告的格式，可能与移走一幢房子里的墙壁一样昂贵，因为二者成本的主要部分都是劳动力。第二章 利用隐喻对编程
34、进行更深刻的理解 10 这两个活动之间还有什么类似之处呢？在建房子中，你不会去建造那些你可以现成买来的东西，比如洗衣机、烘干机，电冰箱、吸尘器等，除非你是个机械迷。同时，你也会去购买已经做好的地毯、门、窗和浴室用品，而不是自己动手建。如果你正在建造一个软件，你也会这样做。你会推广使用高级语言的特点，而不是去编写操作系统一级的代码。你也会利用已经存在的显示控制和数据库处理系统，利用已经通过的子程序。如果样样都自己动手是很不明智的。如果你想修建一幢陈设一流的别墅，情况就不同了，你可能定做全套家具，因为希望洗碗机、冰箱等与你的协调一致，同时你还会定做别具风格的门和窗户。这种定做化的方式与一流软件开发
35、也是非常类似的。为了这一目的，你可能创建精度更高、速度更快的科学公式。你也会设计自己的显示控制、数据库处理系统和自己的子程序，以使整个软件给人以一气呵成，天衣无缝的感觉。当然这两种建造方法也要付出代价，工作的每一步都要依据事先制定好的计划进行。如果软件开发工作的顺序有误，那么这个软件将是难以编码、难以测试和难以调试的。这可能会使整个计划延误甚至失败，因为每个人从事的工作都非常复杂，把它们综合到一起后会使人无所适从。如果你在盖办公楼时工作做得不好，那么在楼内办公的人便可能面临危险。同样，如果你在创建医药、航空电子、空中交通管制、加工控制等软件时工作做得不好，后果也可能是灾难性的。危及别人生命是劣
36、质软件的最可怕后果，但并不是它的唯一危害。如果公司的股东们因为你编写了错误软件而赔钱，那也是令人遗憾的。无论如何，无辜的人们没有义务为你的工作失误而付出代价。对于软件作修改与建造建筑物也有类似之处。如果你要移走的那面墙壁还要支撑其它东西而不仅仅是隔开两个房间，那么你要付出的成本将会更高。同样，对软件做结构性的修改也将比增加或减少外设特征付出更高昂的代价。最后，建筑类比对于超大型软件也是同样适用的。一幢超大型建筑物存在错误的后果将是灾难性的，整个工程可能不得不返工。建筑师们在制定和审查计划时是非常仔细的，他们往往留出安全裕度，多用 10的材料来加强结构总比一幢大楼坍塌要好得多，同时还必须仔细注意
37、工时计划，在修建帝国大厦时，每辆卡车的每次卸货时间都留出了十五分钟的裕度。因为如果有一辆卡车不能在指定时间到达指定的位置，整个计划就有可能被延误。同样，对于超大型软件来说，计划工作需要比一般的大型软件在更高的层次上进行。1977 年，CapersJones 估计说，对于一个拥有 750，000 行代码的系统来说，可能需要多达 600 页的功能定义文件。对于一个人来说，不要说理解这种规模全部的设计，就是读完它也是非常困难的。安全系数对于这种项目是必须的，制定该系统的工时计划尤为重要。当我们在建造与帝国大厦同等经济规模的软件时，我们也需要同等严密的计划。而我们现在才刚刚开始考虑这种规模项目的计划技
38、术。这两者之间的相似还可以推广到其它方面，这就是为什么建筑物创建隐喻是如此强有力的原因。许多常用的软件词汇来源于建筑学，如：软件体系结构、搭结构架、构造、分割代码、插入子程序等等。2 2 2 2.3 3 3 3.5 5 5 5 实用软件技术：智能工具箱（实用软件技术：智能工具箱（实用软件技术：智能工具箱（实用软件技术：智能工具箱（The Intellectual Toolbox）在过去的十几年中，优秀的软件开发人员们积累了几十条关于开发软件的技术和技巧，有 第二章 利用隐喻对编程进行更深刻的理解 11 些像咒语般灵验，这些技术不是规则，它们是分析工具。一个优秀的工匠知道用什么样的工具干哪一样工
39、作，而且知道该如何使用它们。程序员也是如此，关于编程你理解得越深入，你的工具箱里的工具也就越多，何时何地该如何运用它们的知识也就越多。把方法和技巧当作工具是很有益处的，因为这样可以使我们对其有一个正确的态度。不要把最新的“面向对象设计技术”当作上帝赐予的法宝，它不过是一件在某些场合下有用，而在某些场合下又无用的技术。如果你拥有的唯一工具就是一把锤子，那么你就会把整个世界都当作一个钉子。好在没有人会花 500 美元一天的费用来雇佣一个仅告诉你去买一把可以解决一切问题的锤子的研究小组，也没有人建议你丢掉你的改锥、手钻和电烙铁。在软件开发中，常常会有人告诉你用一种方法来代替另外一种方法。这实在不幸，
40、如果你仅仅采用一种方法，那你就会把整个世界都当成那个工具的作用对象。你会失去用更适合的方法解决问题的机会。工具箱隐喻有助于我们保留一切方法、技巧、技术等，并在适当的时候使用它们。2 2 2 2.3 3 3 3.6 6 6 6 复合隐喻（复合隐喻（复合隐喻（复合隐喻（Combing Metaphors）因为隐喻更像是一种启发，而不是公式，所以，它们并不是互相排斥的。你可以同时使用增量隐喻和建筑隐喻。如果你愿意的话，你也可以采用“写”隐喻，或者把写隐喻与耕种隐喻一起使用。只要能激发你的思想，你尽可以采用一切你认为合适的隐喻。使用隐喻是一项模糊的事情。你不得不把它们外推到可以从中受到启发的外延中。如
41、果 你把它过分外推或者推广到了错误方向，它很可能使你误入歧途。就像是再好的工具也有可能被误用一样，你也可能错误使用隐喻。但是，它们的作用将无可置疑地使其成为你的智能工具箱中的一件有力工具。2.4 2.4 2.4 2.4 小小小小 结结结结 隐喻仅仅是启发，而不是公式，因此，它们更倾向于比较随便，无拘无束。隐喻通过把软件开发与你所熟知的事情联系在一起，从而使你对其有更深刻的理解。一些隐喻要好于其它隐喻。把软件创建与建造建筑物类比，表明开发软件前要精心准备，并表明了大规模项目与小 规模项目之间的差别。认为软件开发实践是智能工具箱中的工具进一步表明，每个程序员都有许多自己的工 具，没有任何一种工具是
42、万能的。为每件工作选择合适的工具，是成为一个优秀程序员的首要素质之一。第三章 软件创建的先决条件 12 第三章第三章第三章第三章 软件创建的先决条件软件创建的先决条件软件创建的先决条件软件创建的先决条件 目录目录目录目录 3.1 先决条件重要性 3.2 问题定义先决条件 3.3 需求分析先决条件 3.4 结构设计先决条件 3.5 选择编程语言先决条件 3.6 编程约定 3.7 应花在先决条件上的时间 3.8 改变先决条件以适应你的项目 3.9 小结 相关章节相关章节相关章节相关章节 不同规模程序的不同条件：见第 21 章 管理创建：见第 22 章 设计：见第 7 章 在开始修造一幢房屋之前，建
43、筑工人会评审蓝图，确认所有用料已经备齐，并检查房子的地基。建筑工人为修建摩天大楼和修建狗舍所做的准备工作是截然不同的。但不管是什么样的项目，准备工作总是和需要相适应的，并且应在工程正式开始前做完。本章主要论述在软件创建之前所要做的准备工作，对于建筑业来说，项目的成败往往在开工前就已经决定了。如果基础打得不好，或者项目计划进行得不充分，你所能做的最多也就是防止计划失败，根本谈不上做好。如果你想做一件精美的首饰，那么就得用钻石作原料。如果你用的是砖头，那你所能得到的最好结果不过是块漂亮的砖头而已。虽然本章讲的是软件创建基础工作，但并没有直接论述创建工作。如果你觉得不耐烦，或是你对软件工程生存期循环
44、已经很熟悉了，那么请跳过本章而直接进入下一章。3.1 3.1 3.1 3.1 先决条件重要性先决条件重要性先决条件重要性先决条件重要性 优秀程序员的一个突出特点是他们采用高质量的过程来创建软件。这种过程在计划的开始、中间和末尾都强调高质量。如果你只在一个计划即将结束时强调质量，那你注重的只是测试。当某些人一谈起软件质量时，他们首先想到的便是测试。然而，事实上测试只是全部质量控制策略的一部分。而且并不是最重要的部分。测试既不能消除在正确方向上的错误工作，也不能消除在错误方向上的正确工作的错误，这种错误必须在测试开始之前就清除掉，甚至在创建工作开始之前就要努力清除掉它们。第三章 软件创建的先决条件
45、 13 如果你在一个计划的中间强调质量，那么你强调的是创建活动，这一活动是本书论述的中心。如果在一个计划的开始强调质量，这意味着你计划并要求设计一种高质量的产品。假设你在过程开始时要求设计的是一种菲亚特汽车，你尽可以用你所喜欢的各种手段测试它，但是无论你怎样测试，它也决不会变成一辆罗尔斯罗伊斯牌汽车。或许你所得到的是一辆最好的菲亚特汽车，但如果你想要的是罗尔斯罗伊斯车，你就不得不从计划开始时就提出要求。在软件开发中，当你进行诸如问题定义、规定解决办法等等计划工作时，你所进行的就是这样的工作。由于创建工作处在一个计划的中间，所以，当你开始创建工作时，早期的工作已经奠定了项目成败的基础。在创建工作
46、中，至少你应该知道自己的处境如何，当你发现失败的乌云从地平线上升起时，赶快返回第一阶段。本章其余部分主要讲述准备工作已经作好了。3.1.l 3.1.l 3.1.l 3.1.l 造成准备不足的原因造成准备不足的原因造成准备不足的原因造成准备不足的原因 你也许会认为所有的职业程序员都懂得准备工作的重要性，并且在开始正式工作之前确认所有的先决条件都已得到满足。不幸的是，事实并非如此。一些程序员并不作准备工作，因为他们抵制不了立刻开始进行编码工作的渴望。如果你就是这种程序员，那我对你有两条忠告。第一，阅读一下下一部分工作的内容提示，或许你会从中发现一些你没想到的问题。第二，要注意自己的问题。只要创建过
47、几个大的程序，你就会明白强调准备工作的必要性。不要忘记自己的经验教训。程序员不重视准备工作的另一个原因是管理人员往往不理解那些在创建先决条件上花费时间的程序员。Ed Yourdon 和 Tom DeMarco 等人强调准备工作已经有十五年了。在这期间，他们不时地敲响警钟，或许有一天，管理人员们最终会明白软件开发不仅仅是编写代码。八十年代后期，我曾经在一项军用项目的某一部门中工作。当项目进行到需求分析阶段时，负责这个计划的一位将军前来视察。我们告诉了他目前所处的阶段，并主要谈论了文件编写工作，而这位将军却坚持要看一下代码，我们告诉他目前还没有代码，而他却走进一间正有一百多人工作的房间，转了一圈，
48、企图找到谁在编码。由于未能如愿以偿，他变得有些气急败坏，这位身材高大的将军指着自己身边的工程师喊道：“他在干什么？他一定是在写代码。”事实上，这位软件工程师正在进行文档格式编排的工作，由于这位将军想得到代码，认为那看起来像代码并且想让工程师编码，所以我们不得不骗他说这位工程师写的确实是代码。这可以称为 WISCA 或 WIMP 现象，即：为什么 Sam 没有正在写代码？或 Mary 为什么没正在编程？如果你正在从事的项目经理像那个将军一样，命令你立刻开始编码，说声“是，长官”是很容易的。但这是一个坏的反应，你应该还有几个替代办法。第一，你应该平静地拒绝按照错误顺序工作。如果你与老板的关系很正常
49、的话，那么这太好了。第二，你可以假装正在编码而事实上没有。把一个旧的程序清单放到桌角上，然后埋头从事你的要求和构想文件编写工作，不管你的老板同不同意。这样你可以把工作做得更快更好。从你老板的观点来看，这个忽视是一个福音。第三，你可以用技术项目的开发方式来教育一下老板。这是一个好办法因为这可以增加这 第三章 软件创建的先决条件 14 个世界上开明老板的数量。在下一部分，我们将给出更多在创建活动前做好准备工作的理由。最后，你可以另找一份工作。优秀的程序员是非常短缺的。可以找到更好的工作，干吗非要呆在一个很不开明的程序店里，徒损生命呢？3.1.2 在进行创建工作之前必须做准备工作的论据在进行创建工作
50、之前必须做准备工作的论据在进行创建工作之前必须做准备工作的论据在进行创建工作之前必须做准备工作的论据 假设你已经登上了问题定义的山峰，与负责需求分析的人并肩走了一英里，在结构设计之泉中，洗净了你沾满灰尘的衣服，并且沐浴在已经作好准备的纯洁之水中。那么你就会知道在实现一个系统之前，你应该清楚需要一个系统干什么和需要怎样去干。作为一个工程技术人员，教育你周围的人，让他们懂得技术项目的开发过程，也是你工作的一部分。本书的这一部分可以帮你对付那些还不懂得技术项目开发过程的老板和管理人员。它是关于进行构造设计和问题定义设计权利的延伸论据。在你进行编码、测试和调试之前，学会这些论据，并且和你的老板推心置腹
