重用的情况怎样

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

阅读提示：《人月神话》第十七章继续第十六章讨论的银弹，进一步阐述银弹的存在。本文主要说的是重用的情况。

重用的情况怎样

解决软件构建根本困难的最佳方法是不进行任何开发。软件包只是实现上述目标的方法之一，另外的方法是程序重用。实际上，类的容易重用和通过继承方便地定制是面向对象技术最吸引人的地方。

事情常常就是这样。当某人在新的做事方法上取得了一些经验，新模式就不再像一开始那么简单了。

当然，程序员经常重用他们自己的手头工作。Jones提到：

大多数有丰富经验的程序员都拥有自己的私人开发库，可以使他们使用大约30％的重用代码来开发软件。公司级别的重用能提供70％的重用代码量，它需要特殊的开发库和管理支持。公司级别的重用代码也意味着需要对项目中的变更进行统计和度量，从而提高重用的可信程度。[23]

W.Huang建议用责任专家的矩阵管理来组织软件工厂，培养每个人重用自己的代码的日常工作习惯。[24]

JPL的Van Snyder向我指出，数学软件领域有着软件重用的长期传统：

我们推测重用的障碍不在生产者一边，而在消费者一边。如果一个软件工程师，潜在的标准化软件构件消费者，觉得寻找能满足他需要的构件进行验证，比自行编写的代价更加昂贵时，重复的构件就会产生。注意我们上面提到的“觉得”。它和重新开发的真正投入无关。

数学软件上重用成功的原因有两个：(1)它很晦涩难懂，每行代码需要大量高智商的输入；(2)存在丰富的标准术语，也就是用数学来描述每个构件的功能。因此，重新开发数学软件构件的成本很高，而查找现有构件功能的成本很低。数学软件界存在一些长期的传统—— 例如，专业期刊出版和搜集算法，用适度成本提供算法，出于商业考虑开发的高质量算法(尽管成本有些高，但依旧适度)等—— 使查找和发现满足某人需要的构件比其他的很多领域都要容易。其他领域有时甚至不可能简洁地提出明确的要求。这些因素合在一起，使数学软件的重用比重新开发更有吸引力。

同样的原因，在很多其他领域中也可以发现相同的重用现象，如那些为核反应、天气模型、海洋模型开发软件的代码编制工作。这些领域都是在相同的课本和标准概念下逐步地发展起来的。

现在公司级别的重用情况如何？在这方面有大量的研究。美国国内的实践相对较少，有报道声称在国外重用较多。[25]

Jones报告，在他公司的客户中，所有拥有5 000名以上程序员的机构都进行正式的重用研究，而拥有500名以下程序员的组织，只有不到10％着手重用研究。［26］报告指出，最具有重用潜质的企业中，重用性研究(而非部署)“是活跃和积极的，即使没有完全成功”。Ed Yourdon报告，有一家马尼拉的软件公司，200名程序员中有50名从事供其他人使用的重用模块的开发，“我所见到的个案非常少—— 是由于诸如奖励结构等机构上因素而进行重用研究，而不是技术上的原因”。

DeMarco告诉我，大众市场软件包提供了数据库系统等通用功能，充分地减轻了压力，减少了处在重用模块边缘的开发。“不管怎样，重用的模块一般是一些通用功能。”

Parnas写道：

重用是一件说起来容易，做起来难的事情。它同时需要良好的设计和文档。即使我们看到了非常罕见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。

Ken Brooks关于预测产品所需何种通用化的一些困难的评论：“即使在第五次使用我自己的个人用户界面库的时候，我还是在不断地进行修改。”

真正的重用似乎才刚刚开始。Jones报告，在开放市场上仅有少量的重用代码模块，它们的价格在常规开发成本的1％～20％之间。[27] DeMacro说：

对整个重用现象，我变得有些气馁。对于重用，现有理论几乎是整体缺乏。时间证明了要使模块能够重用，其成本非常高。

Yourdon估计了这个高昂的费用：“一个良好的经验法则是，可重用的构件的工作量是‘一次性’构件的两倍。”[28]在第1章的讨论中，我观察到了真正产品化构件所需的成本。因此，我对工作量比率的估计是三倍。

显然，我们正在看到很多重用的形式和变化，但离我们所期望的还较远，还有很多需要学习的地方。

回书目   上一节   下一节