人月神话（纪念典藏版）

再读软件经典    如品陈年佳酿

《人月神话》是软件工程领域绝无仅有的经典佳作，历时近半个世纪，作者Fred Brooks对大型软件项目管理的经验思考启迪了一代代工程师的实践。

《人月神话》一书的开篇强调了构建“系统产品”与构建“简单程序”的任务不同。研发大型软件系统不是简单程序的堆叠组装。软件开发任务不总是像收割麦子的任务一样可分解，要分析问题性质以及子任务间的依赖关系。软件研发效能的量化估算不能对“人月”“人周”“人天”做简单加法和乘法，正如不能基于个人百米成绩来推算马拉松成绩一样。新手培训、沟通交互都会引入额外的成本，向延期的软件项目添加新人会使项目拖得更久。软件开发任务间复杂的依赖关系需要科学管理，避免无效的人力投入。

软件不可见性和抽象性是导致软件复杂性的根本原因，也是软件工程学科要应对的基本问题。软件系统的复杂性源于参与开发人员的概念模型是不完整和不一致的，正如“一千个人眼中有一千个哈姆雷特”，管理软件项目的复杂性就需要达成各方对软件系统概念模型的局部完整性与一致性。软件项目开发团队的组织要融合开源、群智，以及规模化敏捷组织的最新理念，还要坚守外科手术团队这样的组织结构，持续优化大规模软件系统产品项目的组织与流程。

我国软件产业规模已突破十万亿元，成为软件大国的同时还处在“大而不强”的困境，在系统软件与工业软件领域还面临着被“卡脖子”的风险。《人月神话》一书中的许多经验、观点对于我国关键基础软件技术、产品与产业创新发展具有重要指导意义。

今天作为数字经济社会基础设施的系统软件和工业软件，都是经过数十年长期演进与发展的软件，是软件产业的根技术。如何改变这种受制于人的被动局面？我想在全力投入攻坚之外，还要深入思考、深入探究这类软件产品工程研发的内在规律。实现软件产业高质量发展的关键在于建立开发“能用、管用、好用”的关键系统软件和基础工业软件的工程方法与工具体系。

软件工程“没有银弹”的观点还成立吗？用“塑料薄膜包装的成品软件”无疑已成为历史，但并不妨碍它当年为软件产业发展带来的积极贡献与影响。进入软件开源与大语言模型时代，软件工程领域的“银弹”是否已经出现？大语言模型在代码辅助生成以及算法编程优化等方面展现出强大的能力，它会将软件领域带向何种高度？

再读“人月神话”，今时今日又绘新意。软件定义美好世界， 既是国家示范性软件学院成立的初心，也是清华大学软件学院在建院二十周年时对初心的再次表达。软件系统的形态，软件工程的方法将在实践者的持续探索和研究者的深入思考中不断演进。

                                                                                             王建民    清华大学软件学院院长

                                                                                                     2023年6月

在软件领域，很少能有像《人月神话》一样具有深远影响力和长销不衰的著作。布鲁克斯博士为人们管理复杂项目提供了颇具洞察力的见解，从宏观角度有层次地分析了软件工程的方方面面，不仅逻辑严谨，而且颇具文化底蕴。《人月神话(纪念典藏版)》内容主要来自布鲁克斯博士在IBM公司研发并管理System/360计算机家族和OS/360软件支持包期间的项目管理经验，该项目堪称软件开发项目管理的典范。
《人月神话(纪念典藏版)》英文版一经面世，即引起业内人士的强烈反响，后译为德、法、日、俄、中、韩等多种文字，成为软件开发和管理人员的B读经典。

小弗雷德里克·P.布鲁克斯（Frederick P. Brooks, Jr．1931—2022），图灵奖得主、美国国家科学院院士，对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。
布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作，取得辉煌成功，被认为是“IBM 360系统之父”。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。
布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，因其专业成就和对计算机体系结构的卓越贡献而屡获表彰，包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。

第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章    第二系统效应     /    045

架构师的互动纪律 / 047

自律—第二系统效应 / 048

第6章    传递消息    /    053

书面规约—手册 / 055

形式化定义 / 056

直接整合 / 059

会议和大会 / 059

第7章    为什么巴别塔会失败     /    065

巴别塔的管理教训 / 067

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

项目工作手册 / 068

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

第8章    胸有成竹    /    077

Portman的数据 / 080

Aron的数据 / 081

Harr的数据 / 082

OS/360的数据 /  083

Corbató的数据 /  084

第9章    削足适履    /    085

作为成本的程序空间 / 087

规模控制 /  088

空间技能 /  090

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

第10章     提纲挈领    /    093

计算机产品的文档 / 095

大学科系的文档 /  097

软件项目的文档 /  097

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

第11章     未雨绸缪    /    101

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

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

为变更设计系统 / 104

为变更计划组织架构 /  105

前进两步，后退一步 /  107

前进一步，后退一步 / 109

第12章     干将莫邪    /    111

目标机器 / 114

辅助机器和数据服务 / 116

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

第13章     整体部分    /    123

剔除bug的设计 / 125

构件单元调试 /  127

系统集成调试 /  130

第14章     祸起萧墙    /    135

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

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

地毯的下面 / 140

第15章     另外一面    /    145

需要什么文档 / 148

流程图 / 150

自文档化的程序 / 154

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

摘 要 / 163

介 绍 / 163

根本困难 / 164

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

银弹的希望 / 170

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

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

人狼和其他恐怖传说 / 189

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

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

Harel的分析 / 193

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

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

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

重用的情况怎样 / 203

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

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

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

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

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

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

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

图形界面的成功 / 241

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

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

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

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

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

放弃权力的力量 / 257

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

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

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

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

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

译后记  /      271

在软件领域，很少能有像《人月神话》一样具有深远影响力和长销不衰的著作。布鲁克斯博士为人们管理复杂项目提供了颇具洞察力的见解，从宏观角度有层次地分析了软件工程的方方面面，不仅逻辑严谨，而且颇具文化底蕴。《人月神话(纪念典藏版)》内容主要来自布鲁克斯博士在IBM公司研发并管理System/360计算机家族和OS/360软件支持包期间的项目管理经验，该项目堪称软件开发项目管理的典范。
《人月神话(纪念典藏版)》英文版一经面世，即引起业内人士的强烈反响，后译为德、法、日、俄、中、韩等多种文字，成为软件开发和管理人员的B读经典。

小弗雷德里克·P.布鲁克斯（Frederick P. Brooks, Jr．1931—2022），图灵奖得主、美国国家科学院院士，对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。
布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作，取得辉煌成功，被认为是“IBM 360系统之父”。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。
布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，因其专业成就和对计算机体系结构的卓越贡献而屡获表彰，包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。

　★今天，《人月神话》依然活跃在软件开发各个领域的话题中！我国软件产业规模已突破十万亿元，成为软件大国的同时还处在“大而不强”的困境，在系统软件与工业软件领域还面临着被“卡脖子”的风险。《人月神话》一书中的许多经验、观点对于我国关键基础软件技术、产品与产业创新发展具有重要指导意义。
　　——清华大学软件学院院长 王建民
　　
　　★一些语言老去并消失，一些语言却长存。C和Lisp比SQL要老，但它们也不会那么快离开我们。……Fred Brooks警告我们，不要期望软件开发会有“银弹”，意思是，不要期望单个新技术能提供指数级的改进。
　　——Pro Oracle SQL Development（《Oracle SQL开发进阶》）
　　APress出版社，2023
　　
　　★把团队分为Ops/platform/ML工程团队……会带来沟通和协作的成本。正如Frederick P.Brooks所说，一个程序员一个月能做的事情，两个程序员要做两个月。
　　——Designing Machine Learning Systems（《设计机器学习系统》）
　　O'Reitty出版社，2022
　　
　　★对防御性编程来说，一个根本的、不容更改的事实是：软件充满了缺陷，越是复杂的软件，bug越多。《人月神话》的作者Frederick Brooks对大型复杂系统做了很多的观察。
　　——Beginning Rust Programming（《Rust编程入门》）
　　Wiley出版社，2021