代码大全电子版说明   
----------------------------------------------------------------------------

郑重申明：

    我们的工作的目的仅为大家的研究学习提供方便，以提高软件开发水平。
    所有电子文档不得用于商业目的，否则后果自负。
    同时建议大家去购买原书。
  （现在要做它的电子版的主要原因就是因为该书现在没有出版了。）

----------------------------------------------------------------------------

终于完成了！

这是代码大全的第一次发布，准备在6月份正式发布。
其中如果你在其中发现有错字，格式不一致，线条长了点等细小的缺陷或者建议
请向 : codecomplete@163.net 报告。

让我们共同让这部书达到完美的境界！

本书主页在网站 ： www.delphidevelopers.com 上面。
如果你想发表意见或讨论该书，请进入该书的论坛。


计算机实用软件技术系列丛书
软件开发人员必备工具书
代码大全

STEVE MCCONNELL著
天奥译
熊可宜校
学苑出版社
1993




前言
近年来，关于软件开发的研究，进展是非常迅速的，但是开发实践却并非如此。许多程序仍
然是错误百出，充斥着过时的技术，从而无法满足用户需要。软件工业界和学术界的研究者们，
基本上已经解决了七十年代和八十年代在编程中遇到的问题，并发展了相应的技术。但是直到
现在，这些技术中的大部分仍然没有在软件编程中广泛采用，其主要原因是这些研究成果主要
发表在高度专业性的学术刊物中，普通的程序员们无心顾及。Sridhar Raghavan 和Donald Chand
（1989）的研究表明，一项新技术从诞生到被工业界广泛采用大约需要5到15 年的时间。本书
的目的就是希望能够缩短新技术推广周期，使广大的程序员们可以迅速地获得软件开发的最新
方法与手段。
本书所面向的对象
本书中所收集的研究和编程经验，将有助于你编写出高质量的软件，并且使得开发周期缩
短。通过阅读本书，你将会对自己过去所犯过的错误有更深刻的理解，并懂得今后如何避免它
们。同时，书中所收集的丰富的编程经验也将使你在控制大规模项目和按要求对软件进行修改
和维护时感到得心应手。下面是适合阅读本书的几类人：
经验丰富的程序员
本书适合于想要得到一本全面易用的软件设计指南的那些资深程序员们阅读。由于本书的
中心内容是广大程序员们所熟知的实现过程，因此，无论是受过正规训练而已经验丰富的程序
员，还是完全靠自学成长起来的程序员，都能容易读懂本书所论述的先进技术和方法。
自学成才的程序员
本书尤其适合于很少受过正式专业训练的程序员阅读。1988 年有100，000 人加入了程序
员大军，但其中只有40，000 人是从计算机专业毕业的本科生，其余则几乎全是靠自学成才的。
同时，还有不计其数的其他各行各业的人员需要在工作中自己动手编一些程序。无论你所受到
的正规计算机专业训练多或少，本书都将使你对有效的编程方法和技巧有更深刻的理解。
学生
本书不仅适于实践经验丰富但理论基础薄弱的自学者阅读，同时也适于那些理论基础较好
但几乎不懂得什么编程诀窍的毕业生们阅读。新程序员们的某些实践经验来自于经验丰富的同
事．但主要还是靠自己──吃一堑，长一智──获得的，这往往是一个艰苦而缓慢的过程。通
过本书，可以使你在短时期内获得大量的经验和技巧，从而脱颖而出，所以，不妨一试。
本书的主要特点
完备的软件创建参考本书从质量和编程思想等方面论述了软件构造问题。几乎囊括
了生成子程序、数据的输入输出与控制结构、调试、代码调整策略与技术等各方面的细节。在
使用本书时不必逐页阅读每一个细节，只要在需要时查阅你所感兴趣的章节即可。请把本书作

为手册而不是作为教科书来使用。
方便住实用的检查表书中附有用于检查软件的结构设计、设计方法、模块和子程序等质
量的检查表，以供评估软件质量之用。同时，关于变量名、控制结构、方案布置、测试用例等
等检查表也将使你获益匪浅。
紧跟潮流的新技术书中论述了许多目前最先进的技术，其中许多还只是刚刚投入应
用。由于本书取材于实践经验和最新研究成果两个方面，因此书中所提供的技术在相当长的时
间内都不会过时。
高屋建瓴的观点阅读本书将使你跳出日常琐碎工作的圈子，对软件开发有一个总体上
的把握与认识。繁杂的日常工作往往使程序员们穷干应付而无暇阅读浩如烟海的书籍与资料，
本书丰富而翔实的第一手资料将弥补这一缺憾，使你对软件开发的策略作出正确决策而不致陷
入旷日持久的消耗战中。
通用的概念无论你用的是Pascal、C、C＋＋、Ada、Basic、Fotran 还是COBOL，都
可以从本书所论述的概念、方法和技巧中获得教益。
丰富而典型性的程序示例书中含有大约500 多个正反两方面的程序示例。之所以引入这
么多的示例，是因为笔者就是从各种例程中吸取了大部分的知识、经验与诀窍，因此笔者认为
最好的学习方法是多看例程。例程是用多种语言写成的，因为对于程序员来说，掌握多种语言
是其必不可少的基本素质之一。而且，只有掌握了不受语法规则限制的编程准则，才能真正有
效地提高你的编程效率和质量。为了减轻由于使用多种语言所带来的额外负担，在例程中除非
确有必要，尽量避开了各个语言过于独特的部分。事实上，如果你真正注意每个例程所要说明
的问题的话，那么不必详细理解每个程序段，你也可以清楚地懂得程序的意义。同时，为了进
一步减轻读者的负担，对程序中有意义的部分作了标记。
本书的独特内容
本书关于创建活动的内容是从多个渠道获得的。有关创建活动的资料不仅分布得非常分
散，而且往往没有成文资料，事实上，卓有成效的优秀程序员们所使用的技术并不神秘，但由
于日常事务的繁重和工作任务的重压，程序员们很少有互相交流切磋的时间，因而，他们往往
缺乏有关编程技巧的有效信息来源。
本书中所论述的技术不仅填补了初级与高级编程课本之间的空白，而且也为程序员们提
供了一个有关编程技巧的信息来源。比如当你读过C 语言初级教程之后，你可以再读C 语言高
级教程，然后再去读C 语言高级的高级教程，但读完这些书后，你还能再读什么书呢？你可以
再去读关于PC、Macintosh 或UNIX 等硬件或操作系统的书或者其它有关编程细节的书——因
为你如果不了解实现环境详情的话是无法充分有效地使用语言和程序的。但这只是讨论了编程
的一个方面，最有效的编程技术是那些不受实现环境及语言限制的技术。其它书往往忽略了这
一点，但这恰恰是本书的重点。
写作本书的目的
需要一本关干软件开发有效技术的书，是软件工程界所公认的。由计算机科学技术委员会
所发表的一份报告认为，提高程序质量和生产效率的最有效途径是出版一本关于软件开发有效

技术的书，而且这本书应该以手册的形式来组织。
同时，计算机编程技术的发展史也证明急需一本这方面的书，本书正是出于这个目的
才出版的。
创建活动未受到应有的重视
在一段时期内，软件开发与编码被当作是一回事，但随着软件开发周期中的其它活动被认
识，这一领域内的主要努力全部集中到了项目管理、需求分析、设计和测试等方面，创建活动
成了被遗忘的角落。
与这种现象相对应的思想是认为创建活动是软件开发中无关紧要的部分。于是，刚入门的
程序员被派去进行创建工作，为那些已经由上一阶段设计好的子程序编码。工作几年之后，他
可能会被提升至需求分析或项目管理部门。于是，这位程序员也会自豪地感到他不必再去编码
了。
创建活动是非常重要的
创建活动被忽视的另一个原因是：研究者和程序员们错误地认为与其它开发活动相比，创
建活动是一相对来说比较机械的活动，没有什么值得改进的。没有什么比这种想法离事实更远
了。
在小规模项目中，创建活动约占工作量的80％，在中型项目中也要占50％的工作量，而发
生在创建活动中的错误则占总错误的50％到75％。一项会产生50％到75％错误的工作是有许
多待改进之处的。
一些人认为，虽然创建时的错误占到总错误的50％到75％，但修改它们的费用与分析、设
计错误相比要少得多。的确，创建时的错误修改费用与前期工作错误修改费用相比是要少一些，
但是绝对数并不少、Gerald Weinbers曾在1983 年报道过三个错误，每个错误的修改费用都高
达数百万美元，而每个错误都县一行编码层次上的代码错误。因此，绝不能以修改费用相对少
为理由来忽视创建活动。
具有讽刺意味的是，被忽视的创建活动事实上是唯一任何规模项目都必不可少的活动。
需求可以进行猜想而不必分析；结构可以被省略而不必设计。系统测试也可以不进行。但是，
如果你想有一个程序的话，你就不得不进行创建活动。
本书的独特性
如果创建活动的重要性是非常明显的话，那么本书恐怕就没有出版的必要了。但事实上几
乎没有什么书详细论述了这一主题。只有15年前出版过一本类似内容的书，讲述的是ALGOL、
PL／I、Ratfor等早已过时的语言中的具体问题。其它偶尔也有几本这方面的书，但却是教授们
针对教学用的演示性项目而写的，没有涉及到真正的工程问题。有些则偏激地推崇新技术而不
恰当地贬低了一些非常实用的成熟技术。总之，就内容的新颖、翔实、丰富和实用来看，目前
似乎还没有与本书相匹敌的关于创建活动的书。
编者

第一章欢迎进入软件创建世界
目录
1.1 什么是软件创建（Software Construction）
1.2 软件创建的重要性
1.3 小结
相关章节
本书适合什么人阅读：见前言
阅读本书的益处：见前言
为什么要写这本书：见前言
大家都知道“Construction”这个词在一般情况下的意思是“建筑”。建筑工人盖房子、建
学校、造摩天大楼等时所进行的工作都是建筑。当你小的时候，你用积木进行“建筑工作”。因
此“Construction”指的是建造某个东西的过程。这个过程可能包括：计划、设计、检验等方面的
某些工作，但是，它主要是指在这其中的创造性工作。
1.1  什么是软件创建
开发计算机软件是一项非常复杂的工作，在过去的十五年中，研究者们指出了这项工作所
包括的主要方面，包括：
•  问题定义
•  需求分析
•  实现计划
•  总体设计
•  详细设计
•  创建即实现
•  系统综合
•  单元测试
•  系统测试
•  校正性的维护
•  功能强化
如果你以前从事过一些不太正规的研制工作，你可能以为列出的这个表有些太详细了。而
如果你从事过一些正式的项目，你就会认为这个表非常准确。在正规性与随意性之间达到平衡
是非常困难的．这会在以后章节中讨论。
如果你是自学编程员或是主要从事非正规研制工作，你很可能还没有意识到这些在生产软
件中所需要的工作步骤。在潜意识中，你把这些工作统统称为编程。在非正式项目中，当你在
考虑设计软件时，你所想到的主要活动可能就是研究者们所指的“创建”工作。
关于“创建”的直觉概念是非常准确的，但它往往缺乏正确观点。把创建活动放到与其相

关活动的背景中，有助于我们在适当重视其它非创建工作的同时，把主要精力放在正确的任务
上。图1-1 中给出了创建活动在典型软件生存周期循环中的地位和包括的范围。
正如图中所指出的，创建活动主要指编码和调试过程，但也包括详细设计和测试中的某些
工作。假如这是本关于软件开发所有方面的书，它应该涉及到开发过程所有方面并给予同等重
视。但因为这是一本关于创建技术的手册，所以我们只重点论述创建活动及相关主题。如果把
这本书比喻成一只狗，那么它将用鼻子轻擦创建活动，尾巴扫过设计与测试，而同时向其它开
发活动汪汪叫。
创建活动有时被称作“实现”，它有时被叫作“编码和调试”，有时也称之为“编程”。“编
码”实在不是一个很好的叫法，因为它隐含着把已经设计好的程序机械地翻译成机器语言的过
程；创建则无此含义，它指的是在上述过程中的创造性和决策性活动，在本书中，将交替使用
“实现”、“编程”和“创建”。
图l－l 软件生存周期中软件开发过程的平面图
在图1－1中，给出了软件开发过程的平面图示，而在图12 中，则给了它的立体图示。

图1－1 和图l－2 是创建活动的总体图示，但是，什么是它的细节呢？下面是创建活动
中所包含的一些特定任务。
•  验证基础工作已经完成，可以进行创建工作
•  设计和编写子程序与模块
•  创立数据类型并命名变量
•  选择控制结构并组织语句块
•  找出并修正错误
•  评审其它小组的细节设计和代码，同时接受其它小组评审
•  通过仔细地格式化和征集意见改进编码
•  对分别完成的软件单元进行综合
•  调整编码使其更小、更快

图1－2 本书主要详细论述详细设计、编码、调试和单元测试（所占比例如图示）
要想更详尽地了解创建活动，请参阅目录中每一章的标题。
创建活动包括如此众多的工作，人们可能会禁不住要问：“哪些是创建活动呢？”。一般认
为，非创建活动包括：管理活动、需求分析、软件总体设计、用户交互界面设计、系统测试、
维护工作等。这其中每项工作都与创建工作一样，会直接影响到项目的最终成败（那些需要两
个人以上合作至少一星期项目的成败）。关于这其中每一项活动都有很不错的论著，在本书每一
章后都列出这些书的书名。
1.2  软件创建的重要性
正如我们所知，改进软件质量、提高软件生产率是非常重要的。当今世界许多激动人心的
工程计划中，软件都被广泛地应用：太空飞行、航空、医学与生命保障科学、电影特技、金融
信息的快速处理、科学研究等，这仅是其中的几个例子。如果读者您也认为软件开发是重要的，
那么您就会问，为什么创建活动是重要的？原因如下：
创建活动是开发软件的重要组成部分。随项目规模不同，创建活动在整个开发活动中所占
时间为30％～80％之间，在任何计划中占有如此大时间比例的活动必然会影响计划的成败，这
是不言而喻的。
创建活动在软件开发中处于枢纽地位。分析和设计是创建活动的基础工作，对系统进行测
试以证实创建活动是正确的则是其后续工作，因而创建活动是软件开发的核心工作。
把主要精力集中于创建活动，可以极大地提高程序员的生产效享。由Sackman、Erikson和

Grant在1968 年进行的实验表明，每个程序员的效率系数的变化范围为10～20，这一结果随后
又被其它几个实验所证实。最优秀程序员与普通程序员的巨大差异表明，普通程序员提高效率
的潜力是非常大的。
创建活动的产品，源代码，往往是软件的唯一精确描述。在许多项目中，程序员可得到的
唯一文件便是代码本身。需求说明和设计文档可能会过时，但源代码却总是最新的。因此，源
代码必须具有最好的质量。一个软件成功与否的关键，就在于是否不断运用技术来改进源代码。
而这些技术恰恰是在创建阶段，才能得以最有效的应用。
创建活动是唯—一项必不可少的工作。理论上一个软件项目要经过精心的需求分析和总体
设计，然后再进行创建，接着对其进行彻底的、严格的系统测试。然而，实际工作中的软件项
目，往往越过前两个阶段而直接进行创建活动，最后，由于有太多的错误要修改，系统测试又
被弃之路旁。但是，不管一个项目的计划多么疏漏而又如何匆忙，创建活动都是必不可少的。
无论怎样精简，改进创建活动都是改进软件开发工作的方法。
l.3  小  结
•  创建活动是总体设计和系统测试之间承上启下的工作。
•  创建活动主要包括：详细设计、编码、调试和单元测试。
•  关于创建活动的其它称谓有：实现、编程等。
•  创建活动质量对软件质量有潜在影响。
•  在最后的分析中，对创建活动理解的好坏，决定了一个程序员素质的高低，这将在
本书其余部分论述。

第二章利用隐喻对编程进行更深刻的理解
目录
2.1 隐喻的重要性
2.2 如何使用软件隐喻（Software MetaPhors）
2.3 通常的软件隐喻
2.4 小结
相关章节
设计中的启发：“设计是一个启发过程”见7.5 节
计算机科学的语言可能是所有科学领域中最丰富的。想象一下。你走进一间干净整洁、温
度严格控制在68℉的房间，在这里，你将会找到病毒、蠕虫、臭虫、炸弹、崩溃、火焰、扭曲
的变形者、特洛伊木马和致命错误，在其它领域中，你会遇到这种情况吗？
这些形象的隐喻描述了特定的软件现象。同样形象的隐喻描述了更为广泛的现象，你可以
利用它们来加深你对软件开发的理解。
本书其余部分与本章关于隐喻的论述无关，如果你想了解实质问题可以跳过这一章。但你
要想对软件开发有更清楚的理解，请阅读这一章。
2.1  隐喻的重要性
重大发现往往是从类比中产生的。通过把一个你所陌生的事物与你所熟知的事物比较，你
会对它有进一步的认识，从而形成你对它的独到的深刻理解，这种隐喻方法被称之为“模型化”。
在科学发展史上，充满了利用类比而产生的发现。化学家Kekle梦见一条蛇咬住了自己的尾巴，
醒来后，他由此联想到苯的结构，提出了苯是环形分子的假说，这一假说在1966 年被Barbour
用实验所证实。
分子运动论是在“保龄球”模型上建立起来的。在这里，分子被假想为具有质量并且与保
龄球一样相互之间进行完全弹性碰撞的小球，并且在此基础上，又产生了许多有用的模型。
光的波动理论是在与声音类比的基础上产生的。光与声都具有振幅（亮度与音量），频率（颜
色与音调）和其它类似性质。这种类比是如此有效，以致于科学家们花费了大量时间来寻找像
空气传播声音一样传播光的物质——“以太”，但他们从来也没能找到。有时如此有效的类比这
次却导出了错误结果。
通常，模型的力量在于它能提供生动形象的概念而易被人整个接受。并提供特性、联系和
附加的疑问，有时模型会提出令人困惑的问题，这时往往是由于模型被误解了，那些建筑“以
太”的科学家们，就是因为误解了模型。
正如你所预料的，有些模型比其它的要好。好的模型要简单、与其它模型关联密切、能解释

大部分实验事实和观测现象。
比如一个悬在铁链上来回晃动的大石头。在Galileo之前，Aristotelian 看到它时想到的是重
物必然要从高处落下来停在低处，他认为石头是在克服阻力下落，而当Galileo看到同一现象时，
他认为自己看到了一个单摆，他认为石头是在不断地重复同一运动。
这两个模型所提供的信息是截然不同的。Aristotelian 认为石头是在下落，因而他关心的是
石头的重量、升起的高度及停下所需的时间。而Galileo从单摆模型出发，他关心的是石头的重
量、铁链的半径、石头的角位移及石头每摆一次所需要的时间。Galileo之所以能发现单摆定律，
就是因为他的模型与Aristotelian 不同，从而导致他们提出了不同的问题。
隐喻对加深软件理解所做出的贡献，与它对其它领域所做出的贡献一样大。1973年，在图
灵奖颁奖演说中，Charles Bachman 叙述了从地心说向日心说转移的过程。Ptolemy的地心说统
治了近1400 年。直到1543 年，Copernicus 提出了日心说，这一思想模型的转变导致了一系列
新星的发现，把月亮定义为卫星而不是行星，也改变了人类对自身在宇宙中地位的理解。
Bachman把天文学中从地心说向日心说的转变，与70年代前期在计算机编程中的变化作了
个对比。在当时，数据处理正从以计算机为中心向以数据库为中心进行转变。Bachman 指出，
在旧的处理模式中，数据被当成是一个连续流过计算机的卡片流（以计算机为中心）；而在新的
模式中，数据好比是一个水池，而计算机则偶尔涉足其中（以数据库为中心）。
今天，很难想象谁会认为太阳绕着地球转；也同样难以想象推会把数据当成流过计算机的
卡片流。在这两个例子中，旧的理论一旦被抛弃，很难想象有谁会再把它捡起来。具有讽刺意
味的是，旧理论的相信者认为新理论荒唐可笑，就像我们今天看旧理论一样。
当日心说出现之后，地心说便成了那些相信它的天文学家的阻碍。同样，计算机中心模式
也已经成了那些相信它的计算机科学家的阻碍，因为我们现在已经有了数据库中心模式。
如果一旦看了新的模型，我们便说：“哦，当然正确的模型更有用，其余的都是错误的”，
那只会降低模型的作用。因为这太偏激了。科学史并不是由一系列从“错误”模型到“正确”
模型开关组成的，而是逐渐由“坏的”模型变为“较好”的模型，从包含面较窄到包含面较宽，
从覆盖领域较少到覆盖领域较多。
事实上，很多被较好模型替代的旧模型仍然在发挥作用。例如，工程师们仍然在用牛顿力
学进行工程计算，虽然它已经被相对论力学所取代。
软件科学是一门比其它学科年轻得多的学科，还很不成熟，远未形成一套标准的模型。所
以，现在拥有的是大量相互矛盾的模型。这其中有些很好，有些则很差。因此，对这些模型理
解得好坏，便决定了你对软件开发理解的好坏。
2.2  如何使用软件隐喻
软件隐喻更像是一束搜索灯光，而不是一张地图，它并不会告诉你到哪里去寻找答案；它
只给你以启发，教你如何寻找答案，而不是像数学算法一样硬性规定出到哪里找出答案。
一个公式是一套完整建立的、进行某一些任务的规则。它的结果是可以预测的、确定的，
并不取决于运气。公式会告诉你直接从A点走到B点，中间不准绕路，不准随意顺便访问C、
D、E 或F点，也不准停下来闻一下玫瑰花香或者喝杯咖啡什么的，一切必须按规定来。
启发是一种帮助你寻求答案的技术。它的结果往往和运气有关，因为它只告诉你如何去

找，而并未告诉你应该找到些什么。它不会告诉你怎样直接从点A到点B．甚至很可能它根本
就不知道点A 和点B在哪里。事实上，可以认为启发是一个穿着小丑儿外套的公式。它往往不
可预测，更富有趣味，不会保证一定会发生或不会发生什么。
比如，开车去某人家的公式是这样的：沿167 号公路向南到Sumner，从Bonney 湖出口向
山上开2.4 英里，借助加油站的灯光向左拐，在第一个右转弯处向右转，再拐入通向褐色房子
的公路，寻找的门牌号是北大街714 号。
以下则是一个如何找到我们房屋的启发：找到我们寄给你的最后一封信，开车到回信地址
所说的小镇，到了镇上后随便问哪个人我们住哪儿，别担心，镇上的人都认识我们。如果你谁
也遇不到的话，就打电话找我们。
公式和启发之间的区别是微妙的，这两个例子或许会说明一些问题。从本书的角度来看，
它们之间的主要区别是：它们与答案之间的直接程度。公式给予直接指令；而启发则告诉你该
怎样找到这些指令，或者至少告诉你到哪里寻找它们。
如果有一套指令告诉你该如何解决程序中的问题，这当然会使编程变得很容易，而且结果
也可以预测了。但是编程科学目前还没有那样发达，也许永远也不会。编程中最富于挑战性的
问题便是将问题概念化，编程中许多错误往往都是概念性错误，因为每个程序在概念上都是独
特的，所以创立一套可以指导每一个问题的规则是非常困难，甚至是不可能的。这样，从总体
上知道该如何解决问题，便几乎和知道某一特定问题的答案一样重要了。
你是怎样使用软件隐喻的呢？应该用它来帮助你获得关于编程过程的内在理解，利用它们
来帮助你考虑编程活动，想象解决问题的更好办法。你不要一看到某一行代码就说这与这一章
所使用的某个隐喻相矛盾。随着时间推移，在编程过程当中使用隐喻的程序员肯定比不使用这
一方法的人编写代码更快更好。
2.3  通常的软件隐喻
随着软件的发展，隐喻越来越多，已经到了使人迷惑的地步，Fred Brooks说写软件就像耕
种、猎狼或者在一个沥青矿坑中淹死一只恐龙。Paul Heekel说这就像电影《白雪公主与七个小
矮人》。David Gries说这是科学，Donald Knuth则说这是门艺术，Watts HamPhrey则说这是一个
过程，Peter Freeman说这是个系统，Harlan Mills认为这就像解数学题、做外科手术、或者是宰
一条狗，Mark Spinrad 和Curt Abraham说这更像是开发西部、在冰水中洗澡或者围着营火吃豆
子。
2.3.l  软件书写：写代码（ Writing Code）
开发软件最原始的隐喻出自“写代码”一词。这个写的隐喻说明开发一个程序就像随便写
封信，你准备好纸、笔和墨水，坐下从头写到尾就算完成了。这不需要任何正式计划，你只是
把你要说的都写出来。
许多想法都源于写隐喻。Jon Beitle说，你应该准备好一杯白兰地，一支上等雪茄，与你喜
欢的猎狗一同坐在火边，像一个优秀小说家一样享受一次“自由编程”。Brian 和Kernighan 把
写隐喻风格的书称为《风格要素》（《The Elements of Style》）之后，把他们编程风格的书称作《编
程风格要素》（《The Elements of Programming Style》），程序员们则经常谈论程序的“可读性”。

在一些小问题中，写代码隐喻可以充分描述它们。但是对于其余的问题，它就力不从心了，
它不可能全面彻底地描述软件开发过程。写往往是一种个人活动，而软件开发往往需要许多人
分担各种不同的责任。当你写完一封信时，你把它装进信封并把它寄出去后，你就再也不能改
变它的内容了，无论从哪个角度说，这项工作都已经完成了。软件的内容是很容易改变的却很
难彻底完成。几乎有50％的软件开发工作量是在软件最初发行之后才进行的（Lientz和Swanson，
1980）。编写软件，主要工作量集中在初始阶段。在软件创建中，把精力集中于初始阶段往往不
如在初始工作完成后，再集中精力进行代码的重新调整工作。简而言之，写隐喻往往把软件工
作表示成是一项过于简单而刻板的工作。
不幸的是，写隐喻已经通过我们这个星球上最流行的软件书——Fred Brooks 的《The
Mythical Man Month》而变得永存了。Brooks说，“扔掉一个计划，又有什么呢？”这使得我们
联想到一大堆被扔进废纸篓的手稿。当你写封家常信问候你叔叔时，准备扔掉一封信是可能的，
这也可能是Brooks1975 年写那本书时，当时软件工程的水平。
但是，到了九十年代，再把写隐喻解释为准备扔掉一封信时，恐怕是不合时宜的。现在，
开发一个主要系统的投资已经相当于建一幢十层办公楼或造一艘远洋客轮的费用了。我们应该
在第一次调试时就完成它，或者在它们成本最低时试几次运气，其它几个隐喻较好地解决了说
明达到这一目的的方法问题。
2.3.2 软件播种：生成系统（ Growing a System）
与刻板的写隐喻相反，一些软件开发者认为你应该把创建软件当作播种或培植庄稼。你设
计一小部分，编码一小部分，测试一小部分，然后在某个时候把它加到系统上，通过小步走，
你减小了每次可能遇到的错误。
有时，一项先进的技术可能是通过拙劣的隐喻来表达的。在这种情况下，应努力保留这项
技术并换一个隐喻来表达它。在这里增量技术是先进的，但是种庄稼的比喻则是十分拙劣的。
一次干一点儿的想法可能和植物生长有某种类似之处，但是耕种类比实在太牵强，而且也
令人感到陌生，因而也就很快被后面的隐喻所取代了。很难把耕种隐喻推广到每次做一点儿这
一简单想法之外。如果你来用耕种隐喻，你就会发现自己在谈论给系统计划施肥，减少详细设
计，通过有效地田间管理提高编码产量，最后收获编码。你也会谈论进行轮作，用种小麦代替
大麦，让土地休息一年以提高土壤中的养分。
软件种植隐喻的弱点是你对于软件开发失去了直接控制。你在春天播种代码，最后在秋天
收获一大堆代码。
2.3.3  软件珍珠培植法：系统积累（ System Accretion）
有时候，人们在谈论种植软件而事实上他们指的是软件积累。这两个隐喻是密切联系的，
但是软件积累更深刻一些。“积累”这个词，含有通过外加或吸收，缓慢生长的意思，就像河蚌
逐渐分泌酸钙形成珍珠一样。在地质学上，水中悬浮物逐渐沉积形成陆地的过程也与此相似。
这并不是说你要从水中悬浮物里沉积出代码来；这只意味着你应该学会每次向你的系统中
加一点儿东西。另外一个与积累密切相联的词是增量。增量设计、构造、测试是软件开发的最
强有力工具之一。“增量”一词在设计者心目中还远未达到“结构化”或“面向对象设计”等的
地位，所以迄今为止也没有一本关于这方面的论述，这实在是令人遗憾的，因为这种书中所收
集的技术将具有极大的潜力。