书 · 1975 · 弗雷德里克·P·布鲁克斯(Frederick P. Brooks Jr.)

《人月神话》

计算机与 AI书单第 4 名

一句话结论

软件项目的难处主要在沟通和设计,不在敲代码,所以“人”和“月”不能互换,给延期的项目加人只会更晚。

值不值得读完整本？

值得读,但不必逐章读完。全书很薄,核心十几页就能抓住,其余章节可以按兴趣挑着看。书里关于团队、沟通、设计统一性的判断,今天仍然有用,哪怕你的工作不是写操作系统。

先读第 1、2 章(焦油坑、人月神话)、第 3 章(外科手术团队)、第 4 章(概念完整性)、第 5 章(第二系统效应),这几章是全书骨架。
再读第 11 章(计划扔掉一个)、第 14 章(灾难如何形成),以及 1995 年纪念版新增的第 16 章《没有银弹》和第 19 章(二十年回顾)。第 19 章里作者修正了自己早年的几个观点。
第 8 章(下达命令)的生产率数据、第 9 章(十磅装五磅袋)的内存预算、第 12 章(利器)的工具讨论都带着 1960 至 70 年代的印记,可以快速翻过。
这是随笔集,不是教材,没有习题。读的时候多想想自己团队里有没有类似场景,收获比抠细节大。

核心观点

1. 人月是神话:人和时间不能互换

用“人数 × 月数”估算工作量,只在任务可以完全拆开、互不沟通时才成立。软件几乎从来不是这样,所以给延期的项目加人,通常会让它更晚(布鲁克斯定律)。

为什么：第一,很多任务有先后依赖,不是人多就能并行,就像九个女人不能一个月生出孩子。第二,新人要有人带、要熟悉系统,这会占用老手的时间。第三,人数增加后,沟通渠道按 n(n-1)/2 增长,协调成本比产出涨得快。所以项目已经晚了再加人,先付出的是培训和沟通的代价,进度只会更糟。作者还指出,估算失误的一个常见根源是低估了测试和调试。他给出的经验分配是:1/3 计划、1/6 编码、1/4 组件测试、1/4 系统测试。

2. 概念完整性是系统设计最重要的品质

一个系统最好由一个(或极少数几个)头脑的统一构想来设计。宁可舍弃一些功能,也要保持设计思路一致。

为什么：功能一多,用户要学的东西就多,而如果各部分是不同人按不同思路做的,用户学到的东西就互相不通,系统就难用。设计的一致性来自少数人的决定,而不是委员会的折中。所以作者主张把“架构”(用户看到的接口和行为)和“实现”分开,由少数架构师对用户负责,多数实现者在这个约束里发挥创造力。他认为这样的分工不会压制创造,反而因为有了清晰的边界,实现者更容易做出好东西。

3. 小而精的“外科手术团队”胜过大团队

大系统也要靠少数顶尖的人来设计,其他人围绕他提供支持,而不是让几百人平起平坐地分头写。

为什么：作者引用研究认为,最好的程序员生产率可以是平庸者的五到十倍,可是工资差得并不多,所以人才是最划算的投入。另一方面,人数越多,沟通开销越大,系统的概念完整性越难保证。他借鉴哈兰·米尔斯(Harlan Mills)的“主程序员团队”设想:一位主刀负责设计与编码,配上副手、编辑、文书、工具师、测试员等支持角色。这样十来个人能做出相当于几十上百人才能做的系统,同时保持一个人的设计思路。

4. 第二系统效应与“计划扔掉一个”

设计师做第二个系统时最容易过度设计,把第一次被克制的想法全塞进去。另外,第一个版本往往注定要被推翻,与其假装不会,不如事先计划好。

为什么：第一个系统做的人知道自己没经验,会小心翼翼,往往保守简洁。第二次有了信心,又积压了许多“下次一定加上”的想法,于是系统变得臃肿、过度精致。所以管理者要警惕有过一次成功经验的架构师。同时,因为需求和实现都会在使用中暴露新问题,变化不可避免,第一次做出来的东西往往不是最终要的东西,所以要在计划里留出“先做一个、再重做”的空间。作者在 1995 年版里修正了这一点:他承认当初暗含的是瀑布式流程,更好的做法是增量式地“长出”系统,而不是整体做一遍再整体推倒。

5. 没有银弹:真正的困难在本质而非工具

软件的难点分为“本质困难”(想清楚要做什么、如何设计概念结构)和“偶然困难”(语言、工具、机器带来的麻烦)。偶然困难在逐步被解决,但本质困难不会被某一种新技术一举消除,所以十年内不会有数量级的生产率飞跃。

为什么：作者认为软件的本质有四个特性:复杂性(每个软件的各部分都不同,没有重复可压缩)、一致性(要迁就外部人类制度和系统,没有统一规律)、可变性(软件容易改,所以总被要求改)、不可见性(无法像图纸那样直观呈现)。高级语言、分时系统这类进步,主要是消除了偶然困难。剩下的困难主要在于想清楚要做什么,这个过程没有哪种工具能直接替你完成。所以他的建议是别指望一颗银弹,而是买现成软件、做快速原型、增量构建、培养杰出的设计师。

6. 大项目败在沟通和不诚实的进度上

大项目的失败更多来自团队沟通与协调的崩坏,而不是技术难题;而进度落后是一天天累积的,不是一夜之间发生的。

为什么：巴别塔的故事说明,有共同目标和足够资源的工程也会因为沟通不畅、组织失效而停摆。要降低这类风险,作者主张用少量关键文档(如手册、预算、时间表、组织结构)作为共同基准,因为写下来才会逼人做出决定。进度方面,他说项目怎么晚了一年?答案是一天一天地晚。小滑坡没人在意,是因为里程碑含糊;只要里程碑是明确、可检验的,问题才会早暴露。管理者对坏消息的反应也要冷静,否则下属就会开始粉饰状态。

反对意见

开放源码的集市模式能够化解布鲁克斯定律(埃里克·雷蒙德)

雷蒙德在《大教堂与集市》(1997 年演讲、1999 年成书)里把传统的集中式开发称为“大教堂”,把 Linux 式的开放协作称为“集市”。他提出“只要眼睛足够多,所有 bug 都是浅的”,认为早发布、勤发布、让大量用户兼任测试者和共同开发者,能让大规模协作比布鲁克斯预测的更高效。

敏捷宣言反对重文档、重前期规划(敏捷宣言签署者)

2001 年,十七位开发者在美国犹他州签署《敏捷宣言》,主张“个体和互动高于流程和工具,可工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划”。这与书里强调的先行设计和以文档作基准有张力。布鲁克斯自己在 1995 年版里也承认瀑布模型有问题,转向增量式开发。

信息隐藏比让所有人了解全貌更好(大卫·帕纳斯)

帕纳斯 1972 年的论文《On the Criteria to Be Used in Decomposing Systems into Modules》提出按“信息隐藏”拆分模块:每个模块隐藏一个设计决定,别的模块不需要知道。而书里第七章主张所有程序员都应当了解整个系统,以便沟通。布鲁克斯后来公开承认帕纳斯是对的。

软件的主要问题是社会性的,更应从人和环境入手(汤姆·德马可、蒂姆·李斯特)

《Peopleware》(1987)开篇就说工作中的主要问题与其说是技术性的,不如说是社会性的。他们关注团队凝聚力、工作环境、进度压力的副作用,认为管理者应当营造让人能够进入心流的环境,而不是靠组织结构和进度表去管控。这与书中偏重结构、分工和架构师权威的路线侧重点不同。