前言
在这与这段文字之前，我已经阅读过种种关于《人月神话》的文字。评论者既有刘天北这样的美食家，试图在书页中夹点胡椒面以慢慢品味，为了表现食客特有的风格，他的书页都比别人数得仔细。也有marktsen这样的速食者，试图几句话就打发了自己或者读者那漉漉的饥肠。
阅读这些文字给我带来的收获是：面对《人月神话》，除了表示五体投地的诚服，你既不能做正面言论（那是多余），也不能做负面言论（那是找事）。
这是一本可怕的书。
我大概花了三周的时间来细读这本书——也许很多人会说我应该花更多的时候或者读更多遍——不过，这不是重点。我在书中印证和找寻思想，并为这本书写下了数百个注释。最终我很遗憾我读了电子版本，因而注释被写在了文档中而不是书页上。如果不是这样，我将没有任何方法扼制自己购买这本书的冲动。
然而，我发现我还是应该来写写这本书的读后感想。我没有使用“评论”这样的词汇，是因为任何的（正面或负面的）评论都不可能撼动《人月神话》的地位，而“感想”是唯一可能供读者借鉴而又不引起争论的东西。
下面的文字分成两个主要的部分。一部分是如何读这本书，如果你已经读得很好，那可以跳过去，这是留给别人的。另一部分，则是讨论那个著名的命题：没有银弹——似乎，不讨论这个命题的话，连感想都不成其为感想，沦为空谈了。
一、《人月神话》的结构及其与组织
我对《人月神话》的内容结构做了一些分析，大概如下：
|
章
|
内容说明
|
问题域
|
|
1
|
说明“程序(program)”不是“产品(prodouct)”，更不是“项目(project)”。
说明程序员的心理与情绪因素——这是很重要的一个话题。
|
|
|
2
|
项目的发起、评审与预估（错误的设定项目周期是最大的错误）。
“人月问题”：周期不因为人力投入而变短，事实上它可能更糟糕。
|
项目定义
|
|
3
|
十个人与几百人面临的问题是不同的。
|
团队建设
|
|
4~5
|
从设计阶段开始，即致力于获得和维护概念的完整性。
|
团队管理 - 方向与决策
|
|
6
|
项目过程中的一般性方法。
|
团队管理 - 一般性方法
|
|
7
|
项目组织过程中的沟通问题。
|
团队管理 - 沟通问题
|
|
8~10
|
编码过程中的关键问题：
－项目复杂程度与需要编码的数据呈指数级关系，反过来，减少编码可降低系统复杂性
－数据的表现形式是编程的根本
－文档是必须且重要的，但往往不被关注（主要强调重要性）
|
编码
|
|
11
|
承认变更，承认从需求和设计期就开始的变化。
为应付变化而实现的原型系统。
|
项目定义 - 需求不确定
|
|
12
|
工具带来效能。
|
|
|
13
|
强调测试，以提升品质和保障项目目标。
|
项目管理 - 检测/回顾
|
|
14
|
项目控制：进度与里程碑
|
项目管理 - 控制
|
|
15
|
文档：项目过程文档，包括定义、设计与实现（主要强调方法）
|
项目管理 - 文档化
|
|
16,17
|
没有银弹、再论没有银弹
|
|
|
18,19
|
前十五章的回顾（不包括“银弹”的话题）
|
|
|
20
|
二十年后对上述命题的回顾（包括对银弹现象的进一步解释）
|
|
正如Brooks说到的，在几十年之后的今天，这本书里的现象或者观点已经为整个行业所认知——无论是从实践中的感受，还是从类似《人月神话》这样的书籍中去获知。其中大多数命题与结论，都在这几十年的开发实施中被印证过，所以它们（我指的是这些命题与结论）备受关注。
我只重述Brooks所讲述到的两点。我重述它们的原因，是认为它们还被关注得不够：通过设计来获得系统的一致性，以及更好的文档。
在Brooks的讨论中，不但要“获得”系统的一致性，还是尽力去保障它。Brooks认为“获得和保障”它的角色是并不是同一个人：前者是结构师（第3～4章所论），后者是项目经理（第5章所论）。对于这两个角色（或相似的角色），在第7章“大型编程项目的组织架构”中，Brooks提出：要么产品负责人任总指挥，技术主管充当其左右手；或者反之。Brooks认为前者更适于大型项目，后者更适于（相对）小型的项目。
在人月神话中对这两个角色的用词与我们现在（至少是翻译过来的）用词略有点不一致。事实上书中的产品负责人相当于现在的项目经理，而技术主管相当于技术经理（至少参与系统设计或直接由架构师担任）。
Brooks并没有低估（或错误认识）系统一致性和文档的重要性。但除了这两点未被足够重视之外，我想前十五章的内容不必再复述了。如果你不能理解我为什么不再复述，那可能你需要更多的工程经验或者理论基础。除非你决心认为大师的一切都必须被象圣经一样地重述，但那只是你个人的信仰，或者喜好。
