# 第 18 章 ·《人月神话》的观点：是与非

> 作者把 1975 年版的全部论断原样抽出来逐条自审：哪些被经验证实，哪些已经过时，以及他在哪里被说服改了主意。

---

LLMS 索引： [llms.txt](/llms.txt)

---

题记是塞缪尔·勃特勒的一句俏皮话："我们理解也好，不理解也好，描述都应该简短精练。"这一章正是照此办理——把全书论断压成一张清单，且一个字都不改。

## 这一章讲了什么 {#summary}

作者的动机写在开头：现在对软件工程的了解比 1975 年多得多，那么旧版里的观点，哪些得到了数据和经验的支持，哪些被证明不正确，哪些随着世界变化显得过时？为了便于判断，他把 1975 年版书籍中的论断**毫无更改地抽取出来**，以摘要形式列出，只标注"我认为是正确的：是客观事实和经验中推广的法则"；**方括号里的评论是新版新增的内容**。

所以这一章形式上很像附录，但读法不同：前面的章节是论证，这一章是**判决**。它的价值不在于新信息，而在于一位作者在二十年之后，回头给自己当年的断言逐条打分。

### 清单的覆盖范围与组织

命题按原书章节分组，从第 1 章《焦油坑》一直列到第 15 章《另外一面》——也就是 1975 年原版的全部内容。每一条都是陈述句，可以独立判断真假，例如"编程系统产品的开发工作量是供个人使用的独立构件程序的 9 倍"、"人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的"、"Brooks 法则：为进度落后的项目增加人手，只会使进度更加落后"。

有几条被压缩得极好，几乎可以直接当格言用："良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度"；"任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外"；"人们通常期望项目在接近结束时收敛得快一些，然而情况却是越接近完成，收敛得越慢"。

### 最有意思的部分：他标注了什么

清单里最值得读的是那些**带方括号的更新**，以及少数几条被直接判为过时的命题：

| 原命题 | 二十年后作者的批注 |
| --- | --- |
| 暂存区空间尺寸与每次磁盘访问的程序数量是关键决策 | **已显得过时**——起初因为虚拟内存，后来因为内存成本低廉；现在用户通常会买能装下主要应用全部代码的内存 |
| 库中每个组件需要两个版本（快的和短小的） | **现在看来，这有些过时了** |
| 软件工程师不会常规地对试验性系统做现场测试 | **现在这已成为普遍实践**，beta 版本不同于有限功能的原型，alpha 版本同样是他倡导的做法 |
| 系统编程可供合理选择的语言是 PL/I | **不再正确** |
| 只有懒散和惰性会妨碍高级语言与交互式编程的广泛应用 | **如今它们已在全世界使用** |
| 流程图是被吹捧得最过分的文档 | 补一句更狠的：**流程图是图形化的高级语言**；并说在"很少需要超过一页纸流程图"这一点上，**MILSPEC 军用标准文档需求实在错得很厉害** |
| OS/360 是画蛇添足（第二系统效应）的典型 | **Windows NT 似乎是 20 世纪 90 年代的例子** |
| 采用时间块安排稀缺机时 | **在 1995 年依然如此** |
| Gold 实验：交互式调试中第一次交互的进展是后续的 3 倍 | **我认为在 1995 年依然会如此** |

他也如实记录了自己的判断分歧：第 8 章的 1.5 次幂规律旁边注明"Boehm 的数据并不完全一致，在 1.05 和 1.2 之间变化"；第 4 章"功能与复杂程度的比值"后面补充说这个比值是对易用性的一种测量，要由简单与复杂应用共同验证；"体系结构与实现分离"则被追认为**同样适用于小型项目**。

还有一条我认为是整章最诚实的自我修正。第 7 章工作手册一节里，1975 年的原文写道：

> Parnas 强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
> Parnas 的建议的确是灾难的处方。（Parnas 让我认可了该观点，使我彻底地改变了想法。）

括号里的那句话，是二十年后加上的——**他公开写下了自己当年判断错了**。

此外他从别人的实践里补进了几条当代经验：微软的 Jim McCarthy 说"如果你错过了一个最终期限，确保完成下一条最终期限"；有个微软团队采用了非常小而频繁的阶段（量子）变更，结果每天晚上都需要重新编译生成增长中的系统。

## 我的判断 {#reading}

- 这一章的方法本身值得学：**把论断写成可判真假的陈述句，逐条留档，多年后回头打分**。绝大多数作者（包括我自己写文档时）会把判断埋在流畅的叙述里，以至于几年后无法分辨哪句是当时的观察、哪句是一时的情绪。
- 他标注过时的那些条目有一个共同规律：**它们都依赖于当时的资源约束**（内存贵、机时稀缺、语言选择有限、原型不被接受）。约束一变，结论就失效。这印证了第 5 章的提醒——评估任何建议之前，先问它依赖的假设是否还成立。反倒是"人月不可互换""概念完整性优先""缺陷修复会引入新缺陷"这类关于**人与认知**的命题，二十年过去一条都没过期。
- "Parnas 让我认可了该观点，使我彻底地改变了想法"这句，是全书对我触动最大的一处。它不是客套，而是把一段具体的技术分歧记录成了判断的变更史。**承认自己当年错了，比坚持一条正确结论更需要底气**——尤其在书已经被引用二十年之后。
- 我对"流程图是图形化的高级语言"这个说法持保留：作为对流程图崇拜的反讽很精彩，但它也解释了他为何整体看低可视化表达；在第 17 章里他仍然承认图形化编程"没有令人信服的进步"，而今天的数据流图、状态机图、时序图在工程沟通中的价值是有目共睹的。这是他的一个持续盲区，而不是精确判断。
- 清单里有一类命题我认为被高估了：那些以经验数值形式出现、但样本很小的结论（比如"两个人团队常是最佳的人员使用方法"）。它们在清单里被列为事实，可实际上更接近当时的观察。作者本人在别处承认数据稀缺，这一章却把它们统一称做"客观事实和经验中推广的法则"，标准略宽。
- 不过这一章的存在本身给出了一个反例，反驳了"方法学无用"的悲观解读：**一份可被逐条检验的论断清单，正是方法学能提供的东西**。它不保证结论正确，但它保证结论可被证伪。

## 和我手上的工作有什么关系 {#relevance}

- 我打算借用这个方法给自己的工作留一份"论断清单"：在 `docs/sessions/` 里把当时的判断写成可以判真假的句子，而不是只记"做了什么"。理由很实际——我现在回看几个月前的技术选择时，常常分不清当时是权衡后的结论，还是顺手为之。
- 那些"依赖资源约束"的失效命题，正好是我评估旧技术笔记时最需要的判据。我的笔记里也有大量类似判断（"某某方案太占内存所以不用"），而内存价格与工具链已经变了几轮。以后写这类结论时要**显式写下它依赖的假设**，方便未来的自己判断是否已过期。
- "Parnas 那一句"给了我一个具体的写作纪律：当我在笔记里不认同某个做法时，要写清是**哪一类理由**（知识不足、逻辑不通、还是约束不同）。这样即便后来改主意，也能知道是被什么说服的。这正是阅读协议里"评论要落到具体理由"那一条的实践价值。
- 他补进来的当代经验提醒我：这一章的更新大多来自**别人告诉他的事**。这一节几乎全是引用 Jones、Boehm、McCarthy、Yourdon、DeMarco、Parnas 等人的来信与评论。对我这种独立工作的人来说，这是个缺口——我缺少这种"同行来信"式的纠错渠道，能做的替代是把结论公开写出来，接受读者的反驳。
- 最后一条与这个系列本身有关：这份读书笔记写到现在，已经有十八篇结论。按这一章的思路，我应该在结束语那一篇里回头做同样的事——**列出自己从这本书里得到的论断，并标明哪些是我确认的、哪些还在存疑**。这比再写一段抒情式总结有用得多。

## 一句话记住 {#takeaway}

把论断写成可判真假的句子、逐条留档，二十年后回来打分——这既是对读者的诚实，也是唯一能让经验真正沉淀下来的方式；而经受住时间检验的，几乎都是关于人和认知的命题，不是关于当时资源约束的命题。