[人月神话]读书笔记9--再论没有银弹("No Silver Bullet Refired")

再论《没有银弹》 （“No Silver Bullet”Refired）

★含糊的表达将会导致误解
□创造性活动包括
（1）概念性结构的形式规格化
（2）使用现实的介质来实现
（3）在实际的使用中，与用户交互
在软件开发中，我称为“必要（essence）”的部分是构思这些概念上的结构；我称为“次要（accident）”的部分指它的实现过程。

□现实问题
开发的次要或者表达部分现在已经下降到整个工作的一半或一半以下。由于这部分是现实的问题，所以原则上可以应用测量技术来研究。

如果开发的次要部分少于整个工作的9/10，那么即使不占用任何时间（除非出现奇迹），也不会给生产率带来数量级的提高。因此必须解决开发的根本问题。

□因为是根本困难所以没有希望？
重用和交互的构件开发是解决软件根本困难的一种方法。
软件困难来自“编程人员缺乏构建当今软件的技术”。而我认为根本困难是固有的概念复杂性，无论是任何时间，使用任何方法设计和实现软件的功能，它都存在。
构思软件概念性的结构本身就有复杂性、一致性、可变性及不可见性的特点。不过实际上，每一种困难产生的麻烦都是可以改善的。

□复杂性是层次化的
复杂性是最严重的内在困难，并不是所有的复杂性都是不可避免的。我们的很多软件，但不是全部，来自应用本身随意的复杂特征。
就我的经验而言，在系统工作中所遇到的大多数困难是组织结构上的一些失误征兆。试图为这些现实建模，建立同等复杂的程序，实际上是隐藏而不是解决这些杂乱无章的情况。
很多复杂性并不完全是因为和外部世界保持一致，而是因为实现的本身，例如数据结构、算法、互联性等。而在更高的级别开发软件，使用其它人的成果，或者重用自己的程序--都能避免面对整个层次的复杂性。
层次化：通过分层的模块或者对象
增量化：从而系统可以持续地运行

★Harel的分析
□乐观主义：
我们太过倾向于遵循我们自己的乐观主义(或者是发掘我们出资人的乐观主义)。我们太喜欢忽视真理的声音，而去听从万灵药贩卖者的诱惑。
□“消极”主题
我回顾了一下，发现没有任何一种银弹声称“向我的秘方投资，在十年后你将获得成功”

□银弹就在这里
Harel接着提出了他自己的银弹，一种称为“香草（Vanilla）框架”的建模技术。
建模所针对的确实是软件开发的根本困难，即概念性要素的设计和调试。
适当使用可视化图形可以给工程师和程序员带来可观的成效。而且，这种效果并不仅仅局限于次要问题，开发人员思考和探索的质量也得到了改进。未来的成功系统的开发将围绕在可视化图形表达方式的周围。

□Jone的观点——质量带来生产率
 《没有银弹》如同当时的很多文章，关注于生产率——单位输入对应的软件产出。Jone提出，“不。关注质量，生产率自然会随着提高。”很多代价昂贵的后续项目投入了大量的时间和精力来寻找和修复规格说明中，涉及和实现上的错误。他提供的数据显示了缺乏系统化质量控制和进度灾难之间的密切关系。
　Boehm指出，如果一味追求完美质量，生产率会像IBM的航天软件一样再次下降。
　系统化软件开发方法的发展是为了解决质量问题（特别是避免大型的灾难），而不是出于生产率方面的考虑。

★那么，生产率的情形如何？
生产率数据。生产率的数据非常难以定义、测量和寻找。
当软件包的销量一旦达到百万或者即使只是几千，这时关键的支配性问题就变成了质量、时机、产品性能和支撑成本，而不再是对于客户系统异常关键的开发成本。这里强调了软件包客户化的程度和它的重要性。

★面向对象编程——这颗铜质子弹可以吗？
　面向对象应用在整个开发周期中，但是真正的获益只有在后续开发、扩展和维护活动中才能体现出来。
  为了预期中的，但是有些不确定的收益，冒着风险投入金钱是投资人每天在做的事情。不过，在很多软件公司中，这需要真正的管理勇气，一种比技术竞争力或者优秀管理能力更少有的精神。我认为极度的前期投入和收益的退后是使面向对象技术应用迟缓的最大原因。

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

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

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

在开放市场上仅有少量的重用代码模块，它们的价格在常规开发成本的1％～20％
时间证明了使模块能够重用的成本非常高。
一个良好的经验法则是可重用的构件的工作量是‘一次性’构件的两倍。

对软件重用问题，我们需要研究适当的学问，了解人们如何拥有语言。一些经验教训是显而易见的：
　人们在上下文中学习，所以我们需要出版一些复合产品的例子，而不仅仅是零部件的库。
　人们只会记忆背诵单词。语法和语义是在上下文中，通过使用逐渐地学习。
　人们根据语义上的分类对词汇组合规则进行分组，而不是通过比较对象子集。

★子弹的本质——形势没有发生改变
复杂性是我们这个行业的属性，而且复杂性是我们主要的限制。我们终于可以将焦点集中在更加可行的事情上，而不是空中的馅饼。现在，有可能，我们可以在软件生产率上取得逐步的进展，而不是等待不大可能到来的突破。