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