针对概念上根本问题的颇具前途的方法

作者: ［美］弗雷德里克•布鲁克斯 著UMLChina翻译组 . 出处:清华大学出版社 　2007-12-30 10:54　   砖    好    评论  条 　进入论坛

阅读提示：《人月神话》第十六章论述得是否有一枚银弹，使提高软件的生产率、可靠性和简洁性。本文主要说的是针对概念上根本问题的颇具前途的方法。

针对概念上根本问题的颇具前途的方法

虽然现在软件上没有技术上的突破能够预示我们可以取得像在硬件领域上一样的进展，但在现实的软件领域中，既有大量优秀的工作，也有不引人注意的平稳进步。

所有针对软件开发过程中次要困难的技术工作基本上能表达成以下的生产率公式：

任务时间=   (频率)i×(时间)i

如果和我所认为的一样，工作的创造性部分占据了大部分时间，那些仅仅是表达概念的活动就并不能在很大程度上影响生产率。

因此，我们必须考虑那些解决软件上必要困难的活动—— 即，准确地表达复杂概念结构。幸运的是，其中的一些非常有希望。

购买和自行开发。构建软件最可能的彻底解决方案是不开发任何软件。

情况每一天都有些好转，越来越多的软件提供商为各种眼花缭乱的应用程序提供了质量更好、数量更多的软件产品。当我们的软件工程师正忙于生产方法论时，个人计算机的惊天动地的变化为软件创造了广阔的市场。每个报摊上都有大量的月刊，根据机器的类型，刊登着从几美元到几百美元的各种产品的广告和评论。更多专业厂商为工作站和Unix市场提供了很多非常有竞争力的产品，甚至很多工具软件和开发环境软件都可以随时购买使用。对于独立的软件模块市场，我已在其他地方提出了一些建议。

以上提到的任何软件，购买都比重新开发要低廉一些。即使支付100 000美元，购买的软件也仅仅是一个人年的成本。而且软件是立即可用的！至少对于现有的产品，对于那些专注于该领域开发者的成果而言，它们是可以立刻投入使用的。并且，它们往往配备了书写良好的文档，在某种程度上比自行开发的软件维护得更加完备。

我相信，这个大众市场将是软件工程领域意义最深远的开发方向。软件成本一直是开发的而非复制的成本，所以，即使只在少数使用者之间实现共享，也能在很大程度上减少每个用户的成本。另一种看法是使用软件系统的n个拷贝，将会使开发人员的生产率有效地提高n倍。这是一个领域和行业范围的提高。

当然，关键的问题还是可用性。是否可以在自己的开发工作中使用商用的软件包？这里，有一个令人吃惊的问题。在20世纪50年代到20世纪60年代期间，一个接一个的研究显示，用户不会在工资系统、物流控制、账务处理等系统中使用商用软件包。需求往往过于专业，不同情况之间的差别太大。在20世纪80年代，我们发现这些软件包的需求大为增加，并得到了大规模的使用。是什么导致了这样的变化呢？

并不是软件包发生了变化。它们可能比以前更加通用和更加定制化一些，但并不太多。同样，也不是应用发生了变化。即使有，今天的商业和学术上的需要也比20年以前更加不同和复杂。

重大的变化在于计算机硬件/软件成本比率。在1960年，200万美元机器的购买者觉得他可以为定制的薪资系统支付250 000美元，而这样的系统很容易慢慢地变得不适用。现在，对50 000美元的办公室机器购买者而言，很难想象能为定制薪资系统再支付费用。因此，他们把上述系统的模块进行调整，添加到可用的软件包中。计算机现在如此的普遍，上述的改编和调整是发展的必然结果。

对于我的上述观点也存在一些戏剧性的例外—— 软件包的通用化方面并没有发生什么变化，如电子表格和简单的数据库系统。这些强大的工具出现得如此之晚并如此醒目，产生无数的应用，而其中的一些是非正统的。大量的文章甚至书籍讲述了如何使用电子表格应付很多意想不到的问题。原先作为客户程序，使用Cobol或者报表生成程序编写的大量应用，如今已经被这些工具所取代。

现在很多用户天天操作计算机，使用着各种各样的应用程序，但并不编写代码。事实上，他们中很多人无法为自己的计算机编写任何程序，不过他们非常熟练地使用计算机来解决新问题。

我认为，对于现在的很多组织机构来说，最有效的软件生产率策略是在生产一线配备很多个人计算机，安装好通用的书写、作图、文件管理和电子表格程序以及配备能熟练使用它们的人员，并且把这些人员分配到各个岗位。类似的策略—— 通用的数学和统计软件包以及一些简单的编程能力，同样适用于很多实验室的科学工作者。

需求精炼和快速原型。开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。概念性工作中，没有其他任何一个部分比确定详细的技术需求更加困难。详细的需求包括了所有的人机界面，与机器和其他软件系统的接口。如果失误了，需求工作对系统的影响比其他任何一个部分都大，当然纠正需求的困难也比其他任何一个部分都要大。

因此，软件开发人员为客户所承担的最重要的职能不断重复地抽取和细化产品的需求。事实上，客户不知道自己需要什么。他们通常不知道哪些问题是必须回答的。并且，连必须确定的问题细节常常根本不予考虑，甚至只是简单地回答—— “开发一个类似于我们已有的手工信息处理过程的新软件系统”—— 实际上都过于简单。客户决不会仅仅只要求这些。复杂的软件系统往往是活动的、变化的系统。活动的动态部分是很难想象的。所以，在计划任何软件活动时，要让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一部分，这是非常必要的。

这里，我将向前多走一步，下一个定论。在尝试和开发一些客户定制的系统之前，即使他们和软件工程师一起工作，想要完整、精确、正确地抽取现代软件产品的需求—— 这，实际上也是不可能的。

因此，现在的技术中最有希望的，并且解决了软件的根本而非次要问题的技术，是开发作为迭代需求过程的一部分—— 快速原型化系统的方法和工具。

软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。同时，原型不必受到相同硬件速度、规模或者成本约束的限制。原型通常展示了应用程序的功能主线，但不处理任何如无效输入、退出清除等异常情况。原型的目的是明确实际的概念结构，使客户可以测试一致性和可用性。

现在的软件开发流程是基于如下假设的—— 事先明确地阐述系统，为系统开发竞标，实际进行开发，最后安装。我认为这种假设根本上就是不正确的，很多软件问题就来自这种谬误。因此，如果不进行彻底地调整，就无法消除那些软件问题。其中，一种改进是对产品和原型不断反复地进行开发和规格化。

增量开发—— 增长，而非搭建系统。我现在还记得，在1958年，当听到一个朋友提及搭建(building)，而不是编写(writing)系统时，我所受到的震动。一瞬间，我的整个软件开发流程的视野开阔了。这种暗喻是非常有力和精确的。现在，我们已经理解软件开发是如何类似于其他的建造过程，并开始随意地使用其他的暗喻，如规格说明、构件装备、脚手架(测试平台)(specifications, assembly of components, and scaffolding)。

暗喻“搭建系统”的使用已经有些超出了它的有效期限，是重新换一种表达方式的时候了。如果现在的开发情况与我所考虑的一样，那些概念性的结构非常复杂，以至于难以事先精确地说明和零缺陷地开发，我们必须采用彻底不同的方法。

让我们转向自然界，研究一下生物的复杂性，而不是人们的僵硬工作。我们会发现它们的复杂程度令我们敬畏。光是大脑本身，就比任何对它的描述都要复杂，比任何的模拟仿真都要强大，它的多样性、自我保护和自我更新能力异常丰富和有力。其中的秘密就是逐步发育成长，而不是一次性搭建。

所以，我们的软件系统也必须如此。很多年前，Harlan Mills建议所有软件系统都应该以增量的方式开发。[11]即，首先系统应该能够运行，即使未完成任何有用功能，只能正确调用一系列伪子系统。接着，系统一点一点被充实，子系统轮流被开发，或者是在更低的层次调用程序、模块、子系统的占位符(伪程序)等。

从我在软件工程试验班上开始推动这种方法起，其效果就不可思议。在过去几十年中，没有任何方法和技术能如此彻底地改变我自己的实践。这种方法迫切地要求自上而下设计，因为它本身是一种自上而下增长的软件。增量化开发使逆向跟踪很方便，并非常容易进行原型开发。每一项新增功能，以及针对更加复杂数据或环境的新模块，从已经规划的系统中有机地增长。

这种开发模式对士气的推动是令人震惊的。当一个可运行系统—— 即使是非常简单的系统出现时，开发人员的热情就迸发出来了。当一个新图形软件系统的第一幅图案出现在屏幕上时，即使是一个简单的长方形，工作的动力也会成倍地增长。在开发过程的每个阶段，总有可运行的系统。我发现开发团队可以在4个月内，培育(grow)出比搭建(building)复杂得多的系统。

大型项目同样可以得到与我所参与的小型项目相同的好处。［12］

卓越的设计人员。关键的问题是如何提高软件行业的核心，一如既往的是—— 人员。

我们可以通过遵循优秀而不是拙劣的实践，来得到良好的设计。优秀的设计是可以传授的。程序员的周围往往是最出色的人员，因此他们可以学习到良好的实践。因此，美国的重大策略是颁布各种优秀的现代实践。新课程、新文献，像软件工程研究所(SEI)等新机构的出现都是为了把我们的实践从不足提升到更高的水平。其正确性是勿庸置疑的。

不过，我不认为我们可以用相同的方式取得下一次的进步。低劣设计和良好设计之间的区别可能在于设计方法的完善性，而良好设计和卓越设计之间的区别肯定不是如此。卓越设计来自卓越的设计人员。软件开发是一个创造性的过程。完备的方法学可以培养和释放创造性的思维，但它无法孕育或激发创造性的过程。

其中的差异并不小—— 就像萨列里和莫扎特。一个接一个的研究显示，非常卓越的设计者产生的成果更快、更小、更简单、更干净，实现的代价更少。卓越和一般之间的差异接近于一个数量级。

简单地回顾一下，尽管很多杰出、实用的软件系统是由很多人共同设计开发的，但是那些激动人心、拥有广大热情爱好者的产品往往是一个或者少数伟大设计师们的思想。考虑一下Unix、APL、Pascal、Modula、Smalltalk的界面，甚至Fortran；与之对应的产品是Cobol、PL/I、Algol、MVS/370和MS-DOS(图16-1)。

图16-1 激动人心的产品

因此，尽管我强烈地支持现在的技术转移和开发技能的传授，但我认为我们可以做的最重要工作是寻求培养卓越设计人员的途径。

没有任何软件机构可以忽视这项挑战。尽管公司可能缺少良好的管理人员，但决不会比良好设计人员的需求更加迫切，而卓越的管理人员和设计人员都是非常缺乏的。大多数机构花费了大量的时间和精力来寻找和培养管理人员，但据我所知，它们中间没有任何一家在寻求和培育杰出的设计人员上投入相同的资源，而产品的技术特色最终依赖于这些设计人员。

我的第一项建议是每个软件机构必须决定和表明，杰出的设计人员和卓越的管理人员一样重要，他们应该得到相同的培养和回报。不仅仅是薪资，还包括各个方面的认可—— 办公室规模、家具、个人的设备、差旅费用和人员支持等—— 必须完全一致。

如何培养杰出的设计人员呢？限于篇幅，不允许进行较长的介绍，但有些步骤是显而易见的。

●  尽可能早地、有系统地识别顶级的设计人员，最好的通常不是最有经验的人员；

●  为设计人员指派一位职业导师，负责他们技术方面的成长，仔细地为他们规划职业生涯；

●  为每个方面制定和维护一份职业计划，包括与设计大师的、经过仔细挑选的学习过程，正式的高级教育和短期的课程—— 所有这些都穿插在设计和技术领导能力的培养安排中；

●  为成长中的设计人员提供相互交流和激励的机会。

回书目   上一节   下一节