杀不死的人狼——我读《人月神话》（一） 项目管理编程数据结构

＝＝＝＝＝

前言

＝＝＝＝＝

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

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

这是一本可怕的书。

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

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

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

＝＝＝＝＝

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

＝＝＝＝＝

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

章	内容说明	问题域
1	说明“程序(program)”不是“产品(prodouct)”，更不是“项目(project)”。 说明程序员的心理与情绪因素——这是很重要的一个话题。
2	项目的发起、评审与预估（错误的设定项目周期是最大的错误）。 “人月问题”：周期不因为人力投入而变短，事实上它可能更糟糕。	项目定义
3	十个人与几百人面临的问题是不同的。	团队建设
4~5	从设计阶段开始，即致力于获得和维护概念的完整性。	团队管理 - 方向与决策
6	项目过程中的一般性方法。	团队管理 - 一般性方法
7	项目组织过程中的沟通问题。	团队管理 - 沟通问题
8~10	编码过程中的关键问题： －项目复杂程度与需要编码的数据呈指数级关系，反过来，减少编码可降低系统复杂性 －数据的表现形式是编程的根本 －文档是必须且重要的，但往往不被关注（主要强调重要性）	编码
11	承认变更，承认从需求和设计期就开始的变化。 为应付变化而实现的原型系统。	项目定义 - 需求不确定
12	工具带来效能。
13	强调测试，以提升品质和保障项目目标。	项目管理 - 检测/回顾
14	项目控制：进度与里程碑	项目管理 - 控制
15	文档：项目过程文档，包括定义、设计与实现（主要强调方法）	项目管理 - 文档化
16,17	没有银弹、再论没有银弹
18,19	前十五章的回顾（不包括“银弹”的话题）
20	二十年后对上述命题的回顾（包括对银弹现象的进一步解释）

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

我只重述*s所讲述到的两点。我重述它们的原因，是认为它们还被关注得不够：通过设计来获得系统的一致性，以及更好的文档。

在*s的讨论中，不但要“获得”系统的一致性，还是尽力去保障它。*s认为“获得和保障”它的角色是并不是同一个人：前者是结构师（第3～4章所论），后者是项目经理（第5章所论）。对于这两个角色（或相似的角色），在第7章“大型编程项目的组织架构”中，*s提出：要么产品负责人任总指挥，技术主管充当其左右手；或者反之。*s认为前者更适于大型项目，后者更适于（相对）小型的项目。

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

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

下一节==>>