hnxxcxg软件创建的先决条件.txt

f your application uses MFC in a shared DLL, and your application is in a language other than the

在开始修造一幢房屋之前，建筑工人会评审蓝图，确认所有用料已经备齐，并检查房子的
地基。建筑工人为修建摩天大楼和修建狗舍所做的准备工作是截然不同的。但不管是什么样的
项目，准备工作总是和需要相适应的，并且应在工程正式开始前做完。

对于建筑业来说，项目的成败往往在开
工前就已经决定了。如果基础打得不好，或者项目计划进行得不充分，你所能做的最多也就是
防止计划失败，根本谈不上做好。如果你想做一件精美的首饰，那么就得用钻石作原料。如果
你用的是砖头，那你所能得到的最好结果不过是块漂亮的砖头而已。

优秀程序员的一个突出特点是他们采用高质量的过程来创建软件。这种过程在计划的开始、
中间和末尾都强调高质量。

如果你只在一个计划即将结束时强调质量，那你注重的只是测试。当某些人一谈起软件质
量时，他们首先想到的便是测试。然而，事实上测试只是全部质量控制策略的一部分。而且并
不是最重要的部分。测试既不能消除在正确方向上的错误工作，也不能消除在错误方向上的正
确工作的错误，这种错误必须在测试开始之前就清除掉，甚至在创建工作开始之前就要努力清
除掉它们。

如果你在一个计划的中间强调质量，那么你强调的是创建活动

如果在一个计划的开始强调质量，这意味着你计划并要求设计一种高质量的产品。假设你
在过程开始时要求设计的是一种菲亚特汽车，你尽可以用你所喜欢的各种手段测试它，但是无
论你怎样测试，它也决不会变成一辆罗尔斯——罗伊斯牌汽车。或许你所得到的是一辆最好的
菲亚特汽车，但如果你想要的是罗尔斯——罗伊斯车，你就不得不从计划开始时就提出要求。
在软件开发中，当你进行诸如问题定义、规定解决办法等等计划工作时，你所进行的就是这样
的工作。

由于创建工作处在一个计划的中间，所以，当你开始创建工作时，早期的工作已经奠定了
项目成败的基础。在创建工作中，至少你应该知道自己的处境如何，当你发现失败的乌云从地
平线上升起时，赶快返回第一阶段。

你也许会认为所有的职业程序员都懂得准备工作的重要性，并且在开始正式工作之前确认
所有的先决条件都已得到满足。不幸的是，事实并非如此。

一些程序员并不作准备工作，因为他们抵制不了立刻开始进行编码工作的渴望。如果你就
是这种程序员，那我对你有两条忠告。第一，阅读一下下一部分工作的内容提示，或许你会从
中发现一些你没想到的问题。第二，要注意自己的问题。只要创建过几个大的程序，你就会明
白强调准备工作的必要性。不要忘记自己的经验教训。

程序员不重视准备工作的另一个原因是管理人员往往不理解那些在创建先决条件上花费时
间的程序员。 Ed Yourdon和 Tom DeMarco等人强调准备工作已经有十五年了。在这期间，他
们不时地敲响警钟，或许有一天，管理人员们最终会明白软件开发不仅仅是编写代码。

八十年代后期，我曾经在一项军用项目的某一部门中工作。当项目进行到需求分析阶段时，
负责这个计划的一位将军前来视察。我们告诉了他目前所处的阶段，并主要谈论了文件编写工
作，而这位将军却坚持要看一下代码，我们告诉他目前还没有代码，而他却走进一间正有一百
多人工作的房间，转了一圈，企图找到谁在编码。由于未能如愿以偿，他变得有些气急败坏，
这位身材高大的将军指着自己身边的工程师喊道：“他在干什么？他一定是在写代码。”事实上，
这位软件工程师正在进行文档格式编排的工作，由于这位将军想得到代码，认为那看起来像代
码并且想让工程师编码，所以我们不得不骗他说这位工程师写的确实是代码。

这可以称为WISCA 或WIMP 现象，即：为什么Sam 没有正在写代码？或Mary 为什么没
正在编程？

如果你正在从事的项目经理像那个将军一样，命令你立刻开始编码，说声“是，长官”是
很容易的。但这是一个坏的反应，你应该还有几个替代办法。

第一，你应该平静地拒绝按照错误顺序工作。如果你与老板的关系很正常的话，那么这太
好了。

第二，你可以假装正在编码而事实上没有。把一个旧的程序清单放到桌角上，然后埋头从
事你的要求和构想文件编写工作，不管你的老板同不同意。这样你可以把工作做得更快更好。
从你老板的观点来看，这个忽视是一个福音。

第三，你可以用技术项目的开发方式来教育一下老板。这是一个好办法因为这可以增加这
个世界上开明老板的数量。

最后，你可以另找一份工作。优秀的程序员是非常短缺的。可以找到更好的工作，干吗非
要呆在一个很不开明的程序店里，徒损生命呢？

进行有效程序设计的关键之一就是认识到准备工作是非常重要的。在进行一项大的项目
之前，事先做好计划是明智的。项目越大，需要的计划工作量也越大，从管理人员的角度来看，
计划是指确定一个项目所需要的时间、人力、物力和财力。从技术人员的观点来看，计划是指
弄清楚你想要干什么，以免做出错误的工作而徒耗精力与钱财。有时候你自己并不十分清楚自
己想要的到底是什么？起码刚开始是这样。这时，就会比清楚知道用户需求的人要付出更多努
力，但是，这总比做出一件错误的东西，然后把它扔掉，再从头开始的成本要低得多。

建造一个系统之前，弄清楚怎样开始和如何建造它也是非常重要的，你当然不希望在完全
没有必要的情况下，浪费时间与钱财去钻死胡同而白白增加成本。

创建一个软件系统与其它需要耗费人力与财力的工程是一样的。如果你要造一幢房子，在
开始砌第一块砖之前，你必须事先画好建筑图与蓝图。在你开始浇铸水泥之前，你必须让人评
审你的蓝图并获得通过，在软件开发中事先做计划也与此类似。

在你把圣诞树立起来后，你才会开始装饰它，在没有修好烟囱之前你也不会点燃炉火的，
同样，也没有人会打算在油箱空空的情况下踏上旅程，在软件开发中，你也必须按照正确的顺
序来进行。

程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析；详细设计者以结构设计
者为食，而他自己又成为编码者的食物。

比较软件食物链和真正的食物链，我们会发现如下事实，在一个正常的生态系统中，海鸥
以沙丁鱼为食，沙丁鱼吃鲜鱼，鲜鱼吃水虱，其结果会形成一个正常的食物链。在编程工作中，
如果软件食物链的每一级都可以吃到健康的食物，其结果是由一群快乐的程序员写出的正确代
码。

在一个被污染了的环境中，水虱在受到核沾染的水中游泳，鲫鱼体内积聚了滴滴涕，而沙
丁鱼生活的水域又遭受了石油污染，那么，不幸的海鸥由于处在食物链的最后一环，因此，它
吃的不仅仅是沙丁鱼体内的石油，还有鲜鱼体内的滴滴涕和水虱体内的核废料。

在程序设计中, 如果需求定义遭受了污染，那么这又会影响结构设计，而这将最终影响创建活动。这将导
致程序员们脾气暴躁而营养不良，同时生产出遭受严重污染而充满缺陷的软件。

过去十五年的研究证明，一次完成是最好的选择，不必要的修改是非常昂贵的。
TKW的数据表明，在项目的初期阶段进行设计更改，比如在需求定义和结构设计阶段进行
更改，与在项目的后期，即创建和维护阶段进行更改相比较，其成本要低 50 到 100倍（Boehm
和 Pappecio，1988）。

对IBM的研究也表明了同样结果。在设计开始阶段，如详细设计、编码或单元测试阶段就
消除错误，其成本要比在后期即系统测试和功能强化阶段低10 到100倍（Fagan，1976）。

通常的准则是，一旦引入错误，就尽早发现和消除它。错误在软件食物链中存留的时间越
长，它的危害也就传播得越远。因为需求分析是我们做的第一项工作，因此这时引入的错误在
系统中存留时间最长，危害最大。在软件开发初期引入的错误往往比后来引入的错误传播的面
更广，这也使得早期错误会极大地提高成本。

在需求分析阶段引入的错误，如果马上发现并消除所耗费的成本是1000
美元的话，那么如果到了功能测试阶段才发现和消除，耗费的成本则会高达 25000美元。这说
明我们应该尽早地发现并消除错误。

如果你的老板不相信这些数据，那你可以告诉他，立刻开始编码的程序员往往要比那些先
作计划、而后才编码的程序员花费更长的时间，由NASA 计算机科学公司和马里兰大学联合建
立的软件工程实验室的研究表明，过分地使用计算机（进行编辑、编译、链接、测试等）往往
与低生产率紧密相联。而在计算机旁花费较少时间的程序员，往往更快地完成工作。这是由于
频繁使用计算机的程序员在进行编码和测试之前，花在计划和设计上的时间较少。

在进行创建工作之前你要满足的第一个先决条件，便是必须弄清楚你想要解决的问题是
什么。由于本书的中心内容是创建活动，因此我们不打算在这里论述如何进行问题定义。我们
只想告诉读者如何确认问题定义是否完成，这个定义的质量如何，是否足以作为创建活动的基
础。

问题定义只描述要解决的问题是什么，根本不涉及解决方法。它应该是一个简短的说明，
听起来像一个问题。比如“我们无法跟上指令系统”听起来像一个问题，也是一个好的问题定
义。而“我们需要优化数据入口系统以便跟上指令系统”则是一个糟糕的问题定义，它听起来
不像是个问题而更像是个解决方案。

问题定义的工作是在需求分析之前进行，后者是对问题的更为详尽的分析。

问题定义应该从用户的观点出发，使用用户的语言进行定义。一般来说，它不应该使用计
算机技术术语进行定义。因为最好的解决办法可能并不是一个计算机程序。比如说，你需要一
份关于年度利润的报告，而你已经拥有了一套能产生季度利润的计算机报表系统，如果你的思
路仅仅局限于计算机，那你可能会让人再写一个产生年度利润报告的程序加到这个系统中。为
达到这个目的，你不得不雇用一个程序员编写并调试出一段相应的程序。可是，要是你的思路
开阔一些的话，让你的秘书用计算器把四个季度的利润加到一起，问题不就解决了吗？

当然，如果问题是关于计算机本身时，就是个例外了。比如，计算机的编译速度太慢或者
编程工具的问题太多，那我们只能用技术术语来说明问题了。问题定义错误的后果是你可能浪
费许多时间精力去解决了一个错误问题。这种惩罚往往是双重的，因为真正的问题并没有解决。

明确的需求是很重要的，因为：
明确的需求可以保证是由用户而不是程序员决定系统的功能。如果需求是很清楚的，那么
用户可以对其进行评定，并确认自己是否同意。如果需求不很清楚，那么程序员在编程过程中
就不得不自己决定系统功能，明确的需求防止对用户需求进行猜测。