人月神话（纪念典藏版）

小弗雷德里克·P.布鲁克斯（Frederick P. Brooks, Jr．1931—2022），图灵奖得主、美国国家科学院院士，对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。

布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作，取得辉煌成功，被认为是“IBM 360系统之父”。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。

布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，因其专业成就和对计算机体系结构的卓越贡献而屡获表彰，包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。

这是本书中唯一的一节废话。

我是一个书狂，积习甚深，费尽心机在软件工程、系统工程方面收集了一些书。书，在我看来当分为神品、精品和普通三等，其中神品、精品又分别有一、二和三品之分。我所收集的书中，软件工程书大都属于精品，神品只有两本，Frederick P. Brooks的这本书就属于神品之列。

软件作为一个行业，逐步背起了“solving the wrong problem”

(解决错误的问题)的名声。问题决定解决方案，这也就是说，我们一直在制造错误解决方案！这方面有大量的证据，其中最著名的是美国政府统计署(GAO)的数据：全球最大的软件消费商(美国军方)每年要花费数十亿美元购买软件，而在其所购软件中，可直接使用的只占2%，另外3%需要做一些修改，其余95%都成了垃圾。一句话，不管这些软件是否符合需求规格，它们都显然没有满足客户的需求。面向对象技术并没有给我们带来“神奇的效应”，不管开发商如何吹嘘面向对象OO(Object-Oriented)工具多么万能，也不管那些OO狂热者多

[1]　*编注：该序的作者是王计斌(Dave Wang)，清华大学博士，研究方向包括软件工程和集成产品开发(IPD)，长期从事IPD/CMM推行，创办软件工程研究与实践论坛，现在华为技术有限公司工作。

么毅然地前赴后继，这方面的数据从20世纪80年代以来并没有发生大的改观。

这实在令我们的软件工程专家和从业人员们羞愧，因为它揭示了我们可能一开始就从根本上做错了什么！20世纪90年代中期，当软件工程一代宗师Michael Jackson(非歌坛巨星Michael Jackson)宣布他们的研究结果时，立刻在软件工程界激起了阵阵涟漪。Jackson指出，软件从业人员和方法学大师们只是简单地模仿和照搬其他学科的方法，却将最重要的方面(问题域)忽略了。他指出，面向对象方法和结构化方法对问题域的处理没有什么大的区别，却被人们过分地用美好的词汇美化了：

……从众多面向对象建模的描述中，你可以很清楚地看到这些恶果。而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而，仔细看看，你就会发现它们其实是彻头彻尾的编程对象！如果说有任何和现实世界对象相似的地方，不管是死是活，纯属巧合……

回首软件工程近40年的发展，Jackson哀叹软件行业普遍缺乏专业性，充满了业余人员，“手中有一个锤子，看到什么都是钉子”，谁都可以开发性命攸关的软件。

这就是我们面临的严峻而复杂的现实，也许您会感到震惊！然而在大师Frederick P. Brooks眼里，是那么的平静。因为早在28年前，他就在《人月神话》(The Mythical Man-Month)这本不朽著作中对这些内容做了深入论述。

这本小册子行文优美，思想博大精深，字字真言，精读之有不尽的趣味，藏之又是极珍贵的文献，明眼高人，自能鉴之。

前些年，一位朋友从印度归来，说此书在印度极为普及，我也动起笔来，但惭愧终未成正果。汪颖兄素来勤恳，明知此翻译为“success without applause, diligence without reward”(没有掌声的成功，没有回报的勤勉)，却兢兢业业，反复琢磨，历经单调、繁琐、艰辛的劳动，终于付梓。钦佩之余随即作序共勉。

Dave Wang

SE Forum China

2002年3月于深圳

目　录

第1章 焦油坑 / 001

编程系统产品 / 003

职业的乐趣 / 005

职业的苦恼 / 006

第2章 人月神话 / 009

乐观主义 / 011

人月 / 013

系统测试 / 016

空泛的估算 / 018

重复产生的进度灾难 / 019

第3章 外科手术队伍 / 025

问题 / 027

Mills的建议 / 029

如何运作 / 032

团队的扩建 / 033

第4章 贵族专制、民主政治和系统设计 / 035

概念的完整性 / 037

获得概念的完整性 / 038

贵族专制统治和民主政治 / 039

在等待时，实现人员应该做什么 / 042

第5章 画蛇添足 / 047

结构师的交互准则和机制 / 049

自律—开发第二个系统所带来的后果 / 050

第6章 贯彻执行 / 055

文档化的规格说明—手册 / 057

形式化定义 / 058

直接整合 / 061

会议和大会 / 061

多重实现 / 063

电话日志 / 064

产品测试 / 064

第7章 为什么巴比伦塔会失败 / 067

巴比伦塔的管理教训 / 069

大型编程项目中的交流 / 070

项目工作手册 / 070

大型编程项目的组织架构 / 074

第8章 胸有成竹 / 079

Portman的数据 / 082

Aron的数据 / 083

Harr的数据 / 084

OS/360的数据 / 085

Corbató的数据 / 086

第9章 削足适履 / 087

作为成本的程序空间 / 089

规模控制 / 090

空间技能 / 092

数据的表现形式是编程的根本 / 093

第10章 提纲挈领 / 095

计算机产品的文档 / 097

大学科系的文档 / 099

软件项目的文档 / 099

为什么要有正式的文档 / 100

第11章 未雨绸缪 / 103

试验性工厂和增大规模 / 105

唯一不变的就是变化本身 / 106

为变更设计系统 / 106

为变更计划组织架构 / 107

前进两步，后退一步 / 109

前进一步，后退一步 / 111

第12章 干将莫邪 / 113

目标机器 / 116

辅助机器和数据服务 / 118

高级语言和交互式编程 / 121

第13章 整体部分 / 125

剔除bug的设计 / 127

构件单元调试 / 129

系统集成调试 / 132

第14章 祸起萧墙 / 137

是里程碑还是沉重的负担 / 139

“其他的部分反正会落后” / 141

地毯的下面 / 142

第15章 另外一面 / 147

需要什么文档 / 150

流程图 / 152

自文档化的程序 / 156

第16章 没有银弹—软件工程中的根本和次要问题 / 163

摘要 / 165

介绍 / 165

根本困难 / 166

以往解决次要困难的一些突破 / 171

银弹的希望 / 172

针对概念上根本问题的颇具前途的方法 / 181

第17章 再论“没有银弹” / 189

人狼和其他恐怖传说 / 191

存在着银弹—就在这里 / 191

含糊的表达将会导致误解 / 192

Harel的分析 / 195

Jones的观点—质量带来生产率 / 201

那么，生产率的情形如何 / 201

面向对象编程—这颗铜质子弹可以吗 / 203

重用的情况怎样 / 205

学习大量的词汇—对软件重用的一个可预见但还没有被预言的问题 / 208

子弹的本质—形势没有发生改变 / 209

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

第19章 20年后的《人月神话》 / 235

为什么要出版20周年纪念版本 / 237

核心观点—概念完整性和结构师 / 238

开发第二个系统所引起的后果—盲目的功能和频率猜测 / 240

图形界面的成功 / 243

没有构建舍弃原型—瀑布模型是错误的 / 247

增量开发模型更佳—渐进地精化 / 249

关于信息隐藏，Parnas是正确的，我是错误的 / 254

人月到底有多少神话色彩？Boehm的模型和数据 / 256

人就是一切(或者说，几乎是一切) / 258

放弃权力的力量 / 259

最令人惊讶的新事物是什么？数百万的计算机 / 262

全新的软件产业—塑料薄膜包装的成品软件 / 264

买来开发—使用塑料包装的成品软件包作为构件 / 267

软件工程的状态和未来 / 269

结束语 令人向往、激动人心和充满乐趣的50年 / 271