中文网站：http://www.mmmbook.com/
《人月神话》软玉生香来源：http://www.mmmbook.com/review/beauty.htm
关于我的《人月神话》书评来源：http://www.csdn.net/Develop/Article/17/17031.shtm
书评：
《人月神话》软玉生香
刘天北 著
从尺寸说起
豆豆先生（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 Silver Bullet）》和《再论没有银弹（No Silver Bullet Refired）》；这之后，第1章以下的若干章大约以每次1章半到2章的速度平均分布在5次车中颠簸的早高峰时间（每次约35至40分钟，并有一次坐过站）；最后，一个睡眼惺忪的周六上午让我完成了其余部分--我没法相信，这种"休闲"的阅读形式适用于任何一本其他的技术“名著”（可能的例外是《Peopleware》（《人件》，即将由清华大学出版社出版，译者为UMLChina翻译组方春旭、叶向群），我们一会儿还会谈到它）--或许你明早会带上本《Planning XP》试试。
美味的分析
那么，除了小，这书还有什么好处？对，再就是：它比较好读。我看书也纯粹是"以貌取人"，外表即是一切（法国人说：皮肤是人最深刻的部分）。就像饭菜， "好吃"就好，营养等等在我辈老饕看来，还是第二义，而出于“精神食粮”这话的本意，“好读”也该是对书的最高赞许。
好读有两层意思，读起来容易，和读起来可口。小书不都易读（听说过《逻辑哲学论》？），易读的书也不都可口（有些易读则易读矣，但就好像小儿止咳糖浆，来多了就是对你智力的侮辱--还用提余秋雨老师吗？）但对于一本技术书而言，把自己的主题讲清楚了，而且还易读，也是了不起的成就。好些人写书，一味在“内在美”上下功夫，殊不知，“可接近性”才是首要的一环：我们不也说“可口”、“可人儿”吗？“可”（也是accessibility里的ability）最要紧。
回到正题，谈谈全书的结构：我手上这本MMM的二十年纪念版（Anniversary Edition），共19章（另有简短的前言--初版和再版各一篇--和尾声）。其中，第1到15章是初版内容，最长的一章17页，最短的第五章刨去题图和题记，不过薄薄两张半纸而已。作者称这些章节为"随笔（essays）"，每章各自处理相对独立的主题（“人月”问题、软件项目的人员构成、开发中的交流、文档、排错等等），因而你基本可以不顾及章节间的联系，单独从你感兴趣的任何段落入手。书末的四章里，第18章"Proposition of MMM：True or False?"是对之前各章所有观点的一个列表--一个非常便于翻检和温习的设置；其他的三章（对于“银弹”的两篇讨论和后记）篇幅在二十到四十页，值得专门对待。对于一本初版于多年前的技术书籍，作者并没有逐条修订原有的内容，而选择了重印这些章节，同时在后记中根据二十年来的技术上和认识上的变化检讨得失。
现在，你大概能模糊地看到这本书的样子：很薄，随手翻上去每章很短，并包含大量整页的插图（从侧面看，书页的颜色黑白参差）。换言之，可读性首先来自于外表，你拿起它，马上就感到美味当前。
然后你会注意到书的风格。关于原版技术书的语言风格，我曾经在别处做过一个区分：可读的/可翻译的（对另一对为人熟知的法国概念的蹩脚模仿）。“可读的”风格主要出现在用母语写作的作家笔下。他们能够自如地使用语言中的元素，几乎总能找到对特定概念最合适的表达。这些表达，往往植根于该语言自身，因此很难转换为另一种语言。比如本书作者给讨论“系统空间限制”的一章的标题是“ten pounds in five-pound sack”。对任何具备高考英语水平的读者，这里的意思都非常直观，但是谁能轻易地给出它的中文等价物？"削足适履" ？（我碰巧知道中译本就是这么翻译的。）“五磅的麻袋装十磅”？另一方面，“可翻译的”文本则多为移民作家的产物。对于一个概念，他们缺乏“自然的”表达方式。他们在用别人的语言，一串串的词像临时借用的家具一样摆放那里。你可以简单地逐字翻译这样的文本，甚至可以采用机器翻译而不会犯大错误（从Jacobson et 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年），他根据大量切身实践和教学经验写出了本书，在风格上，也兼具教师的醇厚耐心和工程师的技术素质。我个人最受益于书中随处可见的精彩的比喻。仅仅举几个例子：“焦油坑”、“大教堂”、“外科手术队伍”、“银弹”，就我记忆而言，几乎每一个都是对所指对象最贴切的形容。而这些隐喻的光彩，又通过众多题图、题记（有时不失幽默）的反射，获得了熠熠生辉的效果。
在很多情况下，过分追求“幽默感”也会产生止咳糖浆式的效果。典型的例子是Peopleware。与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 even 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 system effect）”。一个系统设计师在设计第一版系统时，往往出于较弱的自信心以及量力而行的考虑，会尽量剪裁要实现的功能数量。而当第一版系统成功发布，开始第二版的设计时，随着自信心的增强，大量以前被压制的提议都会重现，设计师在塞入新的功能时也会不再那么保守。这很可能导致一个臃肿而缺乏概念完整性的第二版系统（作者的1995年举的例子是Windows 31之后的Windows NT）。第二，整个项目团队的有效组织有助于保证概念完整性。首先，要区分产品人员和开发人员，architect和implementer。这里所说的architect相当于一般而言的产品经理。只有他以及少数的几个人能确定整个的产品需求，而不应把即使是最细微的需求留给开发人员确定。在需求确定的过程中，多次反复，包括来自开发人员的反馈都是必要的，但为确保概念完整性，做出决定的必须是少数，甚至一个人。另外，在开发中可以考虑“外科手术式的”开发团队，即，由唯一的“手术师”（技术大拿）以及多个助手、测试员、联络人员、文档/工具/配置管理员、秘书等组成的队伍。显然无论是产品/开发人员的区分，还是外科手术式队伍的引入，核心原则都是1）职能细分；2）将高要求的工作集中在少数人手中。事实上，作者在其他的章节里说过，提高软件项目的质量的最好办法之一，就是找到合适的人。“伟大”的设计师和普通设计师之间的差别，比采用任何先进工具/方法论/管理模式前后的差别都要大。
银弹和其他
另外，增补部分中的"银弹"是作者独创的又一个概念。在古代的狼人传说中，只有用银质子弹才能制服这些举止无常的怪兽。因此作者也用“银弹”一词，命名人们渴望找到的制服软件项目这头难缠的怪兽的法宝。“没有银弹”意味着，没有任何一种方法（无论技术上的或是管理上的），单单采取它就能将现有的软件开发生产率（可靠度/简洁度）提高一个数量级。
作者的论证是简洁而（在我看来）有效的：软件开发的困难来自两个方面：本质的和偶然的（类似于经院哲学中的本质/偶性的对立）。本质的困难是软件开发本身所固有的，无法用任何方式取消的，而偶然的困难是其中的非本质因素，可以通过引入新工具、方法论或管理模式来消除。关键在于，只要本质的困难在软件开发中消耗百分之十以上的工作量，则即使全部消除偶然困难也不可能使生产率提高10倍。
就像作者其他很多论证一样，读完关于银弹的部分我们或者会说“本来就是这样，这还用说”，或者会说“这么简单的事，我以前怎么没有想到”。正是这种介乎漠视和震惊之间的摇摆体现了这些论断的价值：它们也许在理论上已经是被过分强调、被超越、被唾弃的了，但即便如此，在实践中我们往往连这些基本的原则都会完全不顾。对我们而言，MMM或许首先是一本关于态度的书。它指认的问题首先是，对待软件开发工作时应采取怎样的态度。正是因为某种态度，我们才会热衷于寻找解决一切问题的银弹（RUP也好，CMM也好，XP/Agile也好）而从未诚心诚意地贯彻其中任何一个原则；我们才会急于在系统中塞入一个又一个的功能，无视用户使用时的实际效果；我们才会无法相信自己能够组成“外科手术式”的团队，无法找到不做产品设计的开发人员；我们才会一次次接受形形色色的人月调整，最后把一个个项目带进了“焦油坑”。 据我看来，软件工程首先是一种缓慢的艺术。在这中间，筹划、交流、冥想以及迭代占有很大比重，同样（如果不是更重要的），错位、反复甚至离题也应据有一席之地。即便强调工程的可控性，也难以排除这些必要的环节（记得法式餐馆的例子？）。我们所能做的，是给它们足够的时间和容忍（你知道我不是指纵容延期）。
Brooks在书中提出的两组时间比例也许值得留意：一个“能转（ready to run）”的程序（program）要变成程序产品（programming product）需要3倍于编程的时间；同样，能转的程序变成程序系统（programming system）也需要3倍的时间。准此，则要获得程序系统产品（programming systems product--有点拗口，但仔细想想，还可以？），需要9倍于编写“能转”的程序的时间。另外，他在提到工期规划时说，整个工期的三分之一给计划（planning），六分之一编码（coding），四分之一组件测试和早期系统测试（component test and early system test），最后四分之一系统测试。
类似的划分，远比我们常见的各种方法论中的“里程碑”粗糙得多，但是，有多少人在实践中相信编码应只占整个工期的六分之一甚至九分之一？是否仍是“态度”的原因使我们失去了缓慢工作的能力？我们能把这种态度命名为“浮躁”吗？当所有竞争者都许诺只用那六分之一就能完成整个项目的时候，你能坚持那个“一”吗？我们能像提高气功境界那样，从一种态度跃迁到另一种吗？软件开发是一种气功吗？外科手术、银弹和法国菜都是气功吗？狼人能用气功治好吗？气功也能用人月估计吗？豆豆和老蝙蝠，谁更像狼人？狼人也会浮躁吗？浮躁的狼人究竟更需要气功还是银弹？还是书评？一篇豆豆式的书评？ 尾声
写到这里，我愿意介绍我手头这本MMM的由来。打开书皮，我能看到封底处“Low Price Edition (LPE) authorized for sales only in India, Bangladesh, Pakistan, Nepal, Sri Lanka and Maldives”的字样。原有的书店标签（我印象中是"Graham，250rs"）不知什么时候脱落了。但即使缺乏这个标签，仅仅“LPE”还是能让我回想起在班加罗尔Graham书店度过的那个匆忙的黄昏：第三或四层是技术专区--我开始只找到了Jacobson们的OOSE（有点困惑于复杂的书店布局）--看到另外一人手中的Software Project Survival Guide--我求助于一个店员，他立刻拿给我那本书，和一本MMM--另一个店员看到它们，又递来一本Peopleware.
本文的完成，主要与我一次偶然的阅读有关，与一些论坛中朋友们对MMM的热衷和猜想有关，而与该书中文版本的推出可能只有间接的关系。我无意以此给这个译本作任何广告（我在别处谈过我对中文翻译的态度），当然更无意作反广告。不过，如果现在手头没有这本书的话（一个不幸的假设），我会到书店翻翻那个译本，看看插图复制的质量（尤其是那些铜版画--LPE能让我数清狼人脚爪上的毛），再看看书后还有没有注释和索引。仍然是那些外在的、肤浅的因素会决定我是否购买，就像在任何一个豆豆式书评的作者那里一样。
[参考资料]
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 pp
Peopleware : Productive Projects and Teams, 2nd Ed., by Tom Demarco, Timothy R. Lister, 1999 Dorset House, 264 pp
Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson et al, 1992 Addison-Wesley, 524 pp
Bean: The Movie, by Mel Smith (Director), 1997, 90mins
Jacques Lebrun：关于我的《人月神话》书评
“书评的目的是，让评论者对一本自己看过或者没看过的书说点儿什么。评论只在一个意义上有指导作用，那就是它向书评的读者——包括原书的作者——提供了一些关于评论者的智力的信息，要不就是关于其人品的信息，再不，就是两样都有。”——V. V. Nabokov
不少人抱怨我的文章总是太长。不过相信这次，由于来自纳波科夫的有力援助，我几乎可以免于这个指责：我不想一一回应对《人月神话：一次豆豆式的书评尝试》一文的意见（差点儿忘了说了，我碰巧是该文作者），因为正如那位有名的俄国人所说的，评论与原作无关，只能暴露评论者本人的武功跟智慧。所以即使我以回应的形式再完成一篇三次方形式的评论，那也不能说明我就比别人高了哪怕是哪么一点点，反而只能在一个不祥的循环中越陷越深。
是的，不像很多人相信的那样，评论无损于原作（莫里斯·布朗肖会说，就像早雪无损于寒钟）。Amazon之类的网上书店维护庞大的读者评论，我一直对这个做法感到好奇——这样做至多能体现某本特定书籍的读者群的平均智力罢了。那些散布四处的星星、玫瑰和鸡蛋真的有“指导作用”吗？大众真的高于个人、统计数字真的高于一个清醒的“1”吗？不过若是工业酸雪落在钟上，可能造成致命的腐蚀也未可知。下面的内容主要是澄清一些特定的事实。对于没有读过一篇很长的关于《人月神话》的书评的各位，恳请不必费心往下看：这只是我为自己的钟准备的一层防酸膜。
大约三个月前（2002年11月初），一篇名为《人月神话：一次豆豆式的书评尝试》的文章首发于IBM DevWorks中国网站。文章的完成要追溯到更早的一个假期：几个无所事事的早晨和一些有趣的朋友促成了这篇即兴之作，原本的目的只是在小圈子里分享一些个人意见（类似于人们讲一个笑话）。朋友们读后的反应补偿了打字的痛苦。10月底的一个周末，完全出于尝试（DevWorks页面上的“书评” 字样让我错误地以为他们也积极地征求类似稿件），将原稿发给了DevWorks。之后的过程以令人目眩的加速度进行，短短几天之后，我就在那个可敬的网站上发现了自己的涂鸦——编辑们的高效和专业至今思来令人感佩。
很多事业是无意识的完成的（博尔赫斯在接受大学英文讲席时说，“我一生都在无意识地为这些讲座努力”）。我的书评原本仅基于该书的英文版。当时，中文版推出的消息在论坛上好像弥赛亚的降临一样不断流传，但该文却不是针对它写的，写作过程中也没有和出版该书的“组织”联系上（不过书评的潜在读者也部分地包括了询问该书到底怎样的朋友）。所以当该书中文版正式推出，拙文成了重要的宣传品之一时，事情的发展是我始料未及的。按照IBM DevWorks的约稿协议，该文在发表之后的3个月的所有权益由该网站“独占性地”享有，之后若需引用，应注明“出自DevWorks中国”字样。据我所知Umlchina网站在XProgrammer上使用该文，征得了IBM的许可。
文章刊出，好比是浪子离家，只能交给社会教育了。一些商家请它去促销，却未注明出处，我个人不能负责。这孩子的原名如上所示，至于“软玉生香”什么的，原只是文中的一句话，我同样不为好心人代起的“艺名”负责。另外，有的地方让它上座，尊为“特约书评”，这个“特约”过程我个人不得而知，我也不能负责。需要说明的是，我个人除了从IBM Dev-works中国之外，并未收到任何稿酬，只有清华大学出版社寄来了一部装帧考究的中译本，为我的书房增色不少。换言之，是书评本身，而不是我本人配合了中译本的销售。我的写作碰巧独立于这个过程，而且（透露一个秘密）我碰巧也不靠写作为生（不考虑软件开发也属于广义上的写作），更未从该书的销售中获得任何利益（不考虑书房的装潢因素）。也许从书评本身的质量出发考虑，独立评论是更可取的形式。
另外依我个人的判断，这篇书评生来没有促销天赋。它与其说是个称职的推销员，毋宁是个自说自话的梦呓者。说话时它更喜欢调侃、回忆，语流还不时被突如其来的怪想所打断。那些繁复的、游离在事实之外而又无限自我复制的细节是它最喜爱的非法调味品。它乐意强调形式胜过内容（事实上该文——尽管有一切科技文献的表面装饰——对正统软件工程议题触及有限），并以此作为对匆忙的实用主义者的揶揄和挑衅。一些人不幸被此激怒，却是我不是我的原意——写作时，我脑中的那位潜在读者的长相和这些人没有任何共同之处。
文章刊出后收到了大量反馈。由此我也获得了与不少同行交流的机会，几位热心的读者至今还与我保持通信——这是一个作者能指望的最好奖励，对我来说远比稿酬本身有实际意义。我也时常收到“你好，请问怎样下载该书电子版”的邮件，也许我该就此转行，专攻电子出版？
出于纯粹的好奇，当别人告诉我网上书店和程序员社区都转载了该文时，我也开始不时地关注人们在这些地方的讨论。像在Amazon那里一样，我不时惊讶于“网友们”思路的犀利和文辞的简洁。然而我还是相信纳波科夫的名言，我们说的都与Brooks本人的著作无关，网络只是提供了一个更开放的舞台，人群中的每次孤独的表演都具有一定意义上的自足性和自我反射性。不过，我的上述信念部分地被一位失望的中译本读者颠覆了。在抱怨了该书“没有想象中的好”之后，他/她表示“对那个特邀书评人写的又臭又长的文章实在是愤恨，为了多争一点稿费竟愣是凑出那末（sic）多话来”。
也许我还该再澄清一次？如上所述，书评的目标读者是我的朋友和IBM DevWorks（也许还有Umlchina）的访问者。即使谈论粗俗的经济问题，这位失望者也不是我被付费为之写作的对象，而对于免费用户，也许软件行业的“EULA”在这里也能起作用：在“那末多”话中，没有一个字是说给他/她听的，他/她的愤恨该留给自己。
我还感到有趣的是，究竟“失望者”是什么时候读了这篇书评呢？如果在其读译本之前看的，那么这样“又臭又长的文章”都没有吓退其读书热情，我不免暗叫一声“惭愧（取‘侥幸’意）”；如果是在读译本之后，那么读都读了，失望也失望了，又何苦来忍受这一遭儿“又臭又长”呢？一句话，让失望者看到这篇书评，这是我和（唉，这个平庸而阴险的“和”）他/她双方的不幸。
至此本文的第一个任务已经完成——我相信这足以澄清该文的家世和经济来源，避免进一步的误解和失望——就像哲学家爱说的，写了这么多，解决的实际问题却那么的少——希望该文的敌人已经再一次被“又臭又长”击败，不再往下看了。
第二个任务则相对简单（此前也做过）。作为一个离家浪子，这篇书评不仅举止不羁，而且不学无术。开头引用的那句尼采的话，甚至比这位狂人哲学家本人说得还要夸张：“…mein Ehrgeiz ist, in zehn Saetzen zu sagen, was jeder Andre in einem Buche sagt, - was jeder Andre in einem Buche nicht sagt ...”，尼采只想在“十句话”里说出别人用“一本书”才能说清的东西。由于我勤勉而不可靠的记忆，原文却把“十”和“一”调了个个儿。希望我发明的那个了不起的句子不会成为另一个游子，有一天又在另一个古怪的名称下回到我的门前。
