杀不死的人狼—我读《人月神话》(1)

前言

在这与这段文字之前，我已经阅读过种种关于《人月神话》的文字。评论者既有刘天北这样的美食家，试图在书页中夹点胡椒面以慢慢品味，为了表现食客特有的风格，他的书页都比别人数得仔细。也有marktsen这样的速食者，试图几句话就打发了自己或者读者那漉漉的饥肠。

阅读这些文字给我带来的收获是：面对《人月神话》，除了表示五体投地的诚服，你既不能做正面言论（那是多余），也不能做负面言论（那是找事）。

这是一本可怕的书。
 
我大概花了三周的时间来细读这本书——也许很多人会说我应该花更多的时候或者读更多遍——不过，这不是重点。我在书中印证和找寻思想，并为这本书写下了数百个注释。最终我很遗憾我读了电子版本，因而注释被写在了文档中而不是书页上。如果不是这样，我将没有任何方法扼制自己购买这本书的冲动。

然而，我发现我还是应该来写写这本书的读后感想。我没有使用“评论”这样的词汇，是因为任何的（正面或负面的）评论都不可能撼动《人月神话》的地位，而“感想”是唯一可能供读者借鉴而又不引起争论的东西。

下面的文字分成两个主要的部分。一部分是如何读这本书，如果你已经读得很好，那可以跳过去，这是留给别人的。另一部分，则是讨论那个著名的命题：没有银弹——似乎，不讨论这个命题的话，连感想都不成其为感想，沦为空谈了。

一、《人月神话》的结构及其与组

我对《人月神话》的内容结构做了一些分析，大概如下：

正如Brooks说到的，在几十年之后的今天，这本书里的现象或者观点已经为整个行业所认知——无论是从实践中的感受，还是从类似《人月神话》这样的书籍中去获知。其中大多数命题与结论，都在这几十年的开发实施中被印证过，所以它们（我指的是这些命题与结论）备受关注。

我只重述Brooks所讲述到的两点。我重述它们的原因，是认为它们还被关注得不够：通过设计来获得系统的一致性，以及更好的文档。
 
在Brooks的讨论中，不但要“获得”系统的一致性，还是尽力去保障它。Brooks认为“获得和保障”它的角色是并不是同一个人：前者是结构师（第3～4章所论），后者是项目经理（第5章所论）。对于这两个角色（或相似的角色），在第7章“大型编程项目的组织架构”中，Brooks提出：要么产品负责人任总指挥，技术主管充当其左右手；或者反之。Brooks认为前者更适于大型项目，后者更适于（相对）小型的项目。

在人月神话中对这两个角色的用词与我们现在（至少是翻译过来的）用词略有点不一致。事实上书中的产品负责人相当于现在的项目经理，而技术主管相当于技术经理（至少参与系统设计或直接由架构师担任）。

Brooks并没有低估（或错误认识）系统一致性和文档的重要性。但除了这两点未被足够重视之外，我想前十五章的内容不必再复述了。如果你不能理解我为什么不再复述，那可能你需要更多的工程经验或者理论基础。除非你决心认为大师的一切都必须被象圣经一样地重述，但那只是你个人的信仰，或者喜好。
（责任编辑：张思童）

查看本文来源