Programming 版 (精华区)

发信人: JJason (UFO), 信区: Programming
标  题: 书评：人月神话zz(转载)
发信站: 哈工大紫丁香 (2002年10月25日12:37:54 星期五), 站内信件

【 以下文字转载自 SoftEng 讨论区 】
【 原文由 JJason 所发表 】

以下转载自小百合，电脑技术书
/////////////////////////////////////////////////////////////////////////
发信人: looluo (我爱西西), 信区: Computer_Book
标  题: 书评: 人月神话
发信站: 南京大学小百合站 (Tue Oct 22 10:01:53 2002)

The Mythical Man-Month：一次豆豆式的书评尝试

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2
nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 pp

   豆豆先生（Mr. Bean）赞许惠斯勒的《画家母亲的肖像》，首先谈的一点就是：“这幅
画比较大（quite big），所以了不起（excellent）”。这种批评套路，中国古已有之：
品茶时赞美“热得好”就是。今天我们谈谈Brooks的《The Mythical Man-Month》（中译
为“人月神话”，下简称MMM），也效法英国来的专家，从尺寸说起：这本书的一个突出优
点，在于它比较小。
   小有两点，一是开本，一是页数。尼采说，我的野心是用一句话说完别人十本书才能说
清的事（他还加了一句——甚或是，十本书都说不清的事）。可是对于出版工业，这样的
野心家不要也罢。多数书长，还是因为所涉及的领域本身头绪众多，不过总可以用得上法
国人的俏皮话：他没有时间往短里写。把书写短不是人人都可以办到的，这需要良好的分
寸感和结构感——都是很难在匆忙的IT从业者中找到的素质。是以一般技术书籍，多为人
高马大，卷帙繁浩（当然还有国内影印版的惯常做法，把原来的大开本缩印成小兄弟，但
考虑到增加的阅读难度，结果并没有想象的那么经济）。“大”，对于书——尤其是技术
书——来说，不见得就“了不起”。以我个人的阅读习惯，多于五百页、开本又超过“大
32开”的技术专著，那就只能当字典查，又好比皇宫里的大龄宫女，偶一调情也可，若要
三千宠爱集一身，不啻为非分之想。本来一卷在手，有如软玉生香在抱，总以“轻”、“
薄”为妙，若是庞然巨物，体态狼伉，未免让人产生心理障碍（借此一角向通读了《C++
Primer》的各位致意：你们都可以去做《大内密探零零发》里艳福齐天的皇上）。眼下说
的这本MMM，正是技术书中的赵飞燕，可作字面意义上的掌上舞：大32的开本，算上注释、
索引共332页，要紧的是，每章前的大量篇幅留给题图和题记， 19章下来，实在要读的内
容不到200页。
   如果决定读这本书，你也许可以参照我个人的经验做出时间预算：并非出于固定的读书
计划，而是为了谋杀早晨巴士上的无聊时间，我选中了这本相貌可人、插图众多的MMM（它
的前任似乎是袖珍本的斯各特船长传）。在前一周的周日下午我兴味盎然地覆盖了书末的
三章：后记（“The MMM after 20 years”）、作者著名的单篇论文《没有银弹（No Sil
ver Bullet）》和《再论没有银弹（No Silver Bullet Refired）》；这之后，第1章以下
的若干章大约以每次1章半到2章的速度平均分布在5次车中颠簸的早高峰时间（每次约35至
40分钟，并有一次坐过站）；最后，一个睡眼惺忪的周六上午让我完成了其余部分——我
没法相信，这种“休闲”的阅读形式适用于任何一本其他的技术“名著”（可能的例外是
《Peopleware》，我们一会儿还会谈到它）——或许你明早会带上本《Planning XP》试试
？。

   那么，除了小，这书还有什么好处？对，再就是：它比较好读。我看书也纯粹是“以貌
取人”，外表即是一切（法国人说：皮肤是人最深刻的部分）。就像饭菜， “好吃”就好
，营养等等在我辈老饕看来，还是第二义，而出于“精神食粮”这话的本意，“好读”也
该是对书的最高赞许。
   好读有两层意思，读起来容易，和读起来可口。小书不都易读（听说过《逻辑哲学论》
？），易读的书也不都可口（有些易读则易读矣，但就好像小儿止咳糖浆，来多了就是对
你智力的侮辱——还用提余秋雨老师吗？）但对于一本技术书而言，把自己的主题讲清楚
了，而且还易读，也是了不起的成就。好些人写书，一味在“内在美”上下功夫，殊不知
，“可接近性”才是首要的一环：我们不也说“可口”、“可人儿”吗？“可”（也是ac
cessibility里的ability）最要紧。
   回到正题，谈谈全书的结构：我手上这本MMM的二十年纪念版（Anniversary Edition）
，共19章（另有简短的前言——初版和再版各一篇——和尾声）。其中，第1到15章是初版
内容，最长的一章17页，最短的第五章刨去题图和题记，不过薄薄两张半纸而已。作者称
这些章节为“随笔（essays）”，每章各自处理相对独立的主题（“人月”问题、软件项
目的人员构成、开发中的交流、文档、排错等等），因而你基本可以不顾及章节间的联系
，单独从你感兴趣的任何段落入手。书末的四章里，第18章“Proposition of MMM：True
 or False?”是对之前各章所有观点的一个列表——一个非常便于翻检和温习的设置；其
他的三章（对于“银弹”的两篇讨论和后记）篇幅在二十到四十页，值得专门对待。对于
一本初版于多年前的技术书籍，作者并没有逐条修订原有的内容，而选择了重印这些章节
，同时在后记中根据二十年来的技术上和认识上的变化检讨得失。
   现在，你大概能模糊地看到这本书的样子：很薄，随手翻上去每章很短，并包含大量整
页的插图（从侧面看，书页的颜色黑白参差）。换言之，可读性首先来自于外表，你拿起
它，马上就感到美味当前。
   然后你会注意到书的风格。关于原版技术书的语言风格，我曾经在别处做出过一个区分
：可读的/可翻译的（对另一对为人熟知的法国概念的蹩脚模仿）。“可读的”风格主要出
现在用母语写作的作家笔下。他们能够自如地使用语言中的元素，几乎总能找到对特定概
念最合适的表达。这些表达，往往植根于该语言自身，因此很难转换为另一种语言。比如
本书作者给讨论“系统空间限制”的一章的标题是“ten pounds in five-pound sack”。
对任何具备高考英语水平的读者，这里的意思都非常直观，但是谁能轻易地给出它的中文
等价物？“削足适履” ？（我碰巧知道中译本就是这么翻译的。） “五磅的麻袋装十磅
”？另一方面，“可翻译的”文本则多为移民作家的产物。对于一个概念，他们缺乏“自
然的”表达方式。他们在用别人的语言，一串串的词像临时借用的家具一样摆放那里。你
可以简单地逐字翻译这样的文本，甚至可以采用机器翻译而不会犯大错误（从Jacobson e
t al的OOSE摘引随便一句：“When strong semantics are provided at the behavioral
 description level for all of these fundamental issues, they radically affect
the selection of an appropriate resource structure.”），但是无论译或不译，都很
难马上明白他说的是什么。当然，这只能是对实际情况的最简化的0阶模拟（一些喜欢在行
文中加入俚语的本土作家几乎不能归入任何一边）。但是，当我说出“可读的”时，我首
先想到的就是Brooks和另一位大师Martin Fowler。二者的风格具有不少共同之处：亲切、
不卖弄，能用最普通的英语说明（有时是令我们的汉语绝望的）复杂问题。
   本书的作者Brooks（也许应该说“小”布鲁克斯才对，因为他的全名是“Fredrick P.
 Brooks, Jr.”），曾担任IBM的大型机System/360及其操作系统OS/360的开发项目经理，
被称为“S/360之父”，之后转入大学，执教多年，因而难能一见地在实际项目管理和教学
上都具备世界级水平。在离开IBM近十年之后（1975年），他根据大量切身实践和教学经验
写出了本书，在风格上，也兼具教师的醇厚耐心和工程师的技术素质。我个人最受益于书
中随处可见的精彩的比喻。仅仅举几个例子：“焦油坑”、“大教堂”、“外科手术队伍
”、“银弹”，几乎每一个都是我所知道的对其所指对象最贴切的形容。而这些隐喻的光
彩，又通过众多题图、题记（有时不失幽默）的反射，获得了熠熠生辉的效果。
   在很多情况下，过分追求“幽默感”也会产生止咳糖浆式的效果。典型的例子是Peopl
eware。与MMM相比，那本书总是给我一种推销员教材的印象。二书作者技术背景（很难相
信DeMarco们曾参加过严肃的软件项目）、宗教背景的不同（Brooks是位虔诚的基督徒）也
许可以解释卖弄和朴实、空洞和厚重之间的差距。

   让我们回顾豆豆本人的批评实践。在我看来，它具备难以错认的形式主义特征：主要考
虑“外在”的、形式的（比如画的大小）要素，而忽略作品实际再现的内容——我们记得
豆豆本人唯一一次提及画中的那位老太太时的措辞：停在仙人掌上的、丑恶的老蝙蝠（"a
 hideous old bat who looks like she's got a cactus lodged up her backside"）。
我也要采用这样的策略吗？读者们（我设想，看到这篇书评的各位多数是技术专家）恐怕
会讥之为买椟还珠，另外，MMM的内容也远比“老蝙蝠”更有可谈之处。但即便如此，逐一
考察书中的观点也是不现实的：首先，没有人比作者已经做过的更好，如果你确实需要这
一点，不如去看原书第18章；其次，全书并没有一个一以贯之的中心思想可以提取，对于
比如说沟通、文档、排错、工具等领域，每一个都值得专文仔细讨论。经过考虑，我决定
谈谈那些无需我重读原书就可以回想起来的内容——这也就是经过我的公车阅读实践（基
本上是一个高通滤波过程）幸存下来的精华成分。

   首先是“人月（man-month）”。熟悉软件项目管理的各位肯定清楚，人们常常根据人
月来估计工作量（并相应收费），比如一个项目五人两月完成，那么总工作量就是10人月
。本书以此命名，套用唱片工业的术语，可以说“人月神话”是本“专辑”中主打篇目，
而除了以之为标题的第二章之外，并没有太多内容与此有关。
   称之为“神话”，作者的用意也并非完全否定作为计量方法的人月，而是要厘清这个概
念中隐含的种种错觉。根据我勤勉而不可靠的记忆，这里的主要论断包括：1. 人/月之间
不能换算，换言之，两人做五个月完成，不等于说五人做两个月就能完成；2.（也是最有
争议的一点）在项目后期增加人手，只能使工期进一步推迟；3.项目越大，单位工作需要
的人月越多。或者说，归根结蒂，作者要粉碎的是“人月”概念可以线性把握的神话：无
论是开发人员的人数上，还是工作量本身上的变化，都可能导致最终完成时间的非线性变
化。作者的戏剧性表述是：Adding manpower to a late software project makes it ev
en later. 这个观点事实上没有它看上去那么耸人听闻，而作者在初版以及后记中，都表
示这包含了合理的夸张，后记里甚至援引进一步的研究表示，增加人手不一定会使工期进
一步推迟，不过肯定会使工程效率进一步降低——而如果一定要增加人手，越早越好。

   得出这样的结论，主要的考虑是增加人手带来的隐性花费（人员培训、多人工作时的通
信成本等等）以及项目进程中存在的无法逾越的关键路径（crucial path）。对于项目管
理人员来说，这应该已经是一个不言而喻的真理。但由于最终决策者的压力，实际项目中
却往往会发生与此违背的情况。作者把一份法式餐厅菜单塞进了书中作为插图，我也建议
大家学会菜单上的那个句子：Faire de la bonne cuisine demande un certain temps.
Si on vous fait attendre, c’est pour mieux vous servir, et vous plaire（做好菜
需要一定的时间。如果人家让您多等会儿，那是为了让您最后吃得高兴。） 对于说法语的
客户/老板，这会是一个好的搪塞。

   如果一定要找到贯穿全书的概念的话，“概念完整性（conceptual integrity）”可能
算是一个。宁可少添加一些七七八八的功能（anomalous features）,也应该保证，整个系
统体现的是完整的一套设计理念 ：这是引入概念完整性的含义。概念完整性的受益者包括
最终用户、系统开发者、培训员和服务人员。概念完整性保持得好的系统更易用，需要较
短的培训时间和学习时间，同时也更易于开发。但是在软件生产的实践中，各级决策者都
很容易产生强调功能而忽视概念完整性的倾向。因此我们看到了太多包含大量“功能”，
而就整体而言不知所云的系统，也出现过太多次由于一两个附加功能的实现难度而导致整
个系统开发推迟甚至难产的事例。
   所以作者提出，概念完整性是系统设计中最重要的考虑。在保证概念完整性的各方面中
，我认为作者提出的两点最为有趣。第一，要克服系统的“第二版效应（the second sys
tem effect）”。一个系统设计师在设计第一版系统时，往往出于较弱的自信心以及量力
而行的考虑，会尽量剪裁要实现的功能数量。而当第一版系统成功发布，开始第二版的设
计时，随着自信心的增强，大量以前被压制的提议都会重现，设计师在塞入新的功能时也
会不再那么保守。这很可能导致一个臃肿而缺乏概念完整性的第二版系统（作者的1995年
举的例子是Windows 31之后的Windows NT）。第二，整个项目团队的有效组织有助于保证
概念完整性。首先，要区分产品人员和开发人员，architect和implementer。这里所说的
architect相当于一般而言的产品经理。只有他以及少数的几个人能确定整个的产品需求，
而不应把即使是最细微的需求留给开发人员确定。在需求确定的过程中，多次反复，包括
来自开发人员的反馈都是必要的，但为确保概念完整性，做出决定的必须是少数，甚至一
个人。另外，在开发中可以考虑“外科手术式的”开发团队，即，由唯一的“手术师”（
技术大拿）以及多个助手、测试员、联络人员、文档/工具/配置管理员、秘书等组成的队
伍。显然无论是产品/开发人员的区分，还是外科手术式队伍的引入，核心原则都是1）职
能细分；2）将高要求的工作集中在少数人手中。事实上，作者在其他的章节里说过，提高
软件项目的质量的最好办法之一，就是找到合适的人。“伟大”的设计师和普通设计师之
间的差别，比采用任何先进工具/方法论/管理模式前后的差别都要大。

   另外，增补部分中的“银弹”是作者独创的又一个概念。在古代的狼人传说中，只有用
银质子弹才能制服这些举止无常的怪兽。因此作者也用“银弹”一词，命名人们渴望找到
的制服软件项目这头难缠的怪兽的法宝。“没有银弹”意味着，没有任何一种方法（无论
技术上的或是管理上的），单单采取它就能将现有的软件开发生产率（可靠度/简洁度）提
高一个数量级。
  作者的论证是简洁而（在我看来）有效的：软件开发的困难来自两个方面：本质的和偶
然的（类似于经院哲学中的本质/偶性的对立）。本质的困难是软件开发本身所固有的，无
法用任何方式取消的，而偶然的困难是其中的非本质因素，可以通过引入新工具、方法论
或管理模式来消除。关键在于，只要本质的困难在软件开发中消耗百分之十以上的工作量
，则即使全部消除偶然困难也不可能使生产率提高10倍。

   就像作者其他很多论证一样，读完关于银弹的部分我们或者会说“本来就是这样，这还
用说”，或者会说“这么简单的事，我以前怎么没有想到”。正是这种介乎震惊和庸常之
间的摇摆体现了这些论断的价值：它们也许在理论上已经是被过分强调、被超越、被唾弃
的了，但即便如此，在实践中我们往往连这些基本的原则都会完全忽视。对我们而言，MM
M或许首先是一本关于态度的书。它指认的问题首先是，对待软件开发工作时应采取怎样的
态度。正是因为某种态度，我们才会热衷于寻找解决一切问题的银弹（RUP也好，CMM也好
，XP/Agile也好）而从未诚心诚意地贯彻其中任何一个原则；我们才会急于在系统中塞入
一个又一个的功能，无视用户使用时的实际效果；我们才会无法相信自己能够组成“外科
手术式”的团队，无法找到不做产品设计的开发人员；我们才会一次次接受形形色色的人
月调整，最后把一个个项目带进了“焦油坑”。
   据我看来，软件工程首先是一种缓慢的艺术。在这中间，筹划、交流、冥想以及迭代占
有很大比重，同样（如果不是更重要的），错位、反复甚至离题也应据有一席之地。即便
强调工程的可控性，也难以排除这些必要的环节（记得法式餐馆的例子？）。我们所能做
的，是给它们以足够的时间和容忍（你知道我不是指纵容延期）。
   Brooks在书中提出的两组时间比例也许值得留意：一个“能转（ready to run）”的程
序（program）要变成程序产品（programming product）需要3倍于编程的时间；同样，能
转的程序变成程序系统（programming system）也需要3倍的时间。准此，则要获得程序系
统产品（programming systems product——有点拗口，但仔细想想，还可以？），需要9
倍于编写“能转”的程序的时间。另外，他在提到工期规划时说，整个工期的三分之一给
计划（planning），六分之一编码（coding），四分之一组件测试和早期系统测试（comp
onent test and early system test），最后四分之一系统测试。
   类似的划分，远比我们常见的各种方法论中的“里程碑”粗糙得多，但是，有多少人在
实践中相信编码应只占整个工期的六分之一甚至九分之一？是否仍是“态度”的原因使我
们失去了缓慢工作的能力？我们能把这种态度命名为“浮躁”吗？当所有竞争者都许诺只
用那六分之一就能完成整个项目的时候，你能坚持那个“一”吗？我们能像提高气功境界
那样，从一种态度跃迁到另一种吗？软件开发是一种气功吗？外科手术、银弹和法国菜都
是气功吗？狼人能用气功治好吗？气功也能用人月估计吗？豆豆和老蝙蝠，谁更像狼人？
狼人也会浮躁吗？浮躁的狼人究竟更需要气功还是银弹？还是书评？一篇豆豆式的书评？


   写到这里，我愿意介绍我手头的这本MMM的由来。打开书皮，我能看到封底处“Low Pr
ice Edition (LPE) authorized for sales only in India, Bangladesh, Pakistan, Ne
pal, Sri Lanka and Maldives”的字样。原有的书店标签（我印象中是“Graham，250rs
”）不知什么时候脱落了。但即使缺乏这个标签，仅仅“LPE”还是能让我回想起在班加罗
尔Graham书店度过的那个匆忙的黄昏：第三或四层是技术专区——我开始只找到了Jacobs
on们的OOSE（有点困惑于复杂的书店布局）——看到另外一人手中的Software Project S
urvival Guide——我求助于一个店员，他立刻拿给我那本书，和一本MMM——另一个店员
看到它们，又递来一本Peopleware…
   本篇书评的完成，主要与我一次偶然的阅读有关，与一些论坛中朋友们对MMM的热衷和
猜想有关，而与该书中文版本的推出可能只有间接的关系。我无意以此给这个译本作任何
广告（我在别处谈过我对中文翻译的态度），当然更无意作反广告。不过，如果现在手头
没有这本书的话（一个不幸的假设），我会到书店翻翻那个译本，看看插图复制的质量（
尤其是那些铜版画——LPE能让我数清狼人脚爪上的毛），再看看书后还有没有注释和索引
。仍然是那些外在的、肤浅的因素会决定我是否购买，就像在任何一个豆豆式书评的作者
那里一样。

--
http://bbs.nju.edu.cn/cgi-bin/bbs/showfile?name=Pig_week.gif

※ 来源:．南京大学小百合站 http://bbs.nju.edu.cn [FROM: 
203.93.220.115]                                                 

--

     人生，就是一团欲望：
     欲望没有满足的时候就是痛苦，
     欲望被满足的时候就是无聊；
     人生就是在痛苦与无聊之间徘徊。

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.229.69]
--
※ 转载:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: 202.118.229.69]