书评：人月神话(不朽的软件工程名著)

已经有好几周没有写书评了，今天突然想起来要写一写。由于上次的书评是 关于C++的，今天打算写写软件工程方面的。对于软件工程而言，我个人认为到目前为止，尚未有哪本书的影响力和深刻程度能够超越《人月神话》（全名 是：The Mythical Man-Month — Essay on Software Engineering）。于是考虑来聊一下鼎鼎大名的《人月神话》。如果你已经熟读此书，并且自认为深刻掌握其精华，本帖子你就不必再看了。

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

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

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

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

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

　　★我个人的建议
　　啰嗦了这么多，最后来说说我个人的几点建议：
　　如果你从来没有看过本书，那赶紧去找一本来，并全部读一遍（不一定要按顺序看）。
　　如果你以前看的是老版本，那赶紧去找来新版（20周年纪念版），并重点看看增补的4个章节。
　　如果你已经把新版全部看完，今后可以考虑定期（例如每隔一两年）再拿出来翻一翻。