人月神话书评

作者是书籍质量的一个主要保证。《人月神话》的作者：Frederick Phillips Brooks（以下简称 Brooks）。这位老兄最牛X的成就是在60年代（那时他才【29岁】）主持并完成了一个同样很牛X的IBM 360系统的开发。
　　IBM 360后来被誉为是人类从原子能时代进入信息时代的标志。该项目不光具有历史意义，而且在软件工程方面非常有代表性（因为其规模和复杂度）。为了给大伙儿加深印象，列举该项目的几个数据如下：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
软件人员总数　　2000　　四十年后，微软的Windows 2003团队也就5000人
软件总费用　　　5亿$　　发明第一个原子弹的曼哈顿工程也不过才花20亿$
开发周期　　　　4年
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
　　注意，上述仅仅是软件方面的统计。

　　最终，IBM 360项目并没有完成全部的预定目标，但是对于这个史无前例的项目，居然没有中途夭折，本身已经算是奇迹了。后来，Brooks 在1975年（距今已30多年）把他所写的一些软件工程方面的随笔（很多都与 IBM 的360项目有关）整理出版，也就是我们今天点评的《人月神话》。

★本书的结构

　　前面已经说了，Brooks 当年是把他写过的一些随笔整理出书的，所以书中的各个章节相对来说比较独立。因此你不一定按照排版的顺序来阅读。比如俺每次重读这本书都只是挑选其中一两个章节来看。

★本书的看点

　　虽然本书的每个章节都称得上是经典，但限于篇幅，只把俺印象最深刻的几章介绍一下。

◇第2章 关于【人月】的误导性

　　这是本书最有名气的章节。在本章，Brooks明确反对使用“人月”这个极具欺骗性的度量单位。因为“人月”这个称谓暗示着“人”和“月”是可以互换的。
　　即使到今天为止，还是有大量的编程人员、测试人员、项目经理和软件公司老板在【错误地】使用“人月”来衡量软件开发的工作量，实际上，当某人宣称某工作量是6个人月时，这句话本身是没有太大意义的。一般来说，1个人干6个月的工作，6个人在1个月内几乎很难完成。所以俺在沟通工作量时，都会明确地讲清楚，需要几个人干几个月。
　　另外，Brooks 根据人月的不可互换推导出一个怪论：向进度落后的项目增加人手会导致项目更加落后。这个怪论是如此出名，以至于后来被称为“Brooks 法则”。这个法则蛮有用滴，每当有上级领导企图通过增加人手来赶进度时（往往在项目后期），俺都会搬出这个法则来拒绝这种企图。

◇第3章 关于团队的组成

　　为了解决前几章中提到的大型团队的种种困难，Brooks 提出了一种新的解决方案：把大型团队拆分为若干个类似于外科手术式的小团队。
　　每个小团队有一名主程序员（类似于主刀医生），所有的问题分解和功能定义都通过主程序员来完成，以此来降低沟通成本。并且，每个主程序员配备若干个平庸的人帮他/她打下手，也很符合现实情况（还记得“二八原理系列”中提到的优秀人员和平庸人员的比例吗？）。具体的角色职责我就不细说了，书上都有。

◇第16、17章 关于【没有银弹】的真知灼见

　　实际上第16章“没有银弹”的内容来自于作者在1986年作的报告，后来才加入书中。第17章“再论没有银弹”是20周年版加入的。
　　据作者在本书的“20周年纪念版”中宣称，“没有银弹”是引发最多争议的章节。不过我个人认为：虽然引发最多争议，但是这两章却是全书最重要、最深刻且最有价值的章节。即使你从事的工作和软件工程无关，你也应该认真阅读它。
　　Brooks 在第16章分析了软件开发的【根本性困难】（复杂性、非一致性、易变性和不可见性）和【次要性困难】。分析完根本性困难和次要性困难之后，作者断言：未来十年内，【不可能】有某种技术突破（银弹）能够彻底解决“根本性困难”，从而导致软件开发效率有数量级的提高。
　　现在，时间已经过去了远远不止十年。在“没有银弹”发表之后，软件界冒出了数不清的新玩意儿（比如面向对象、组件技术、设计模式、CMM、UML、敏捷开发、RAD、等等），很多新玩意儿的创造者都号称他们发明了银弹。但实际上没有哪个新技术能够经受住时间的考验并真正获得银弹的称号。

★俺的建议

　　啰嗦了这么多，最后来说说俺的几点建议：

1. 如果你从来没有看过本书，那赶紧去找一本来，并全部读一遍（不一定要按顺序看）。
2. 如果你以前看的是老版本，那赶紧去找来新版（20周年纪念版），并重点看看增补的4个章节。
3. 如果你已经把新版全部看完，今后可以考虑定期（例如每隔一两年）再拿出来翻一翻。