《人月神话》出版后的网友评论

《人月神话》出版后的网友评论

摘编自各网络论坛 [2003/04/24]

gcc_0000 个人看法：作者有预见性，抓住软件的本质！5-star 但是在当前软件工程讨论中急功近利的气氛下，不久就会受到攻击(大规模的)。 本书阐述作者的观点(当时是1975年)。这些观点在之后的软件工程学术发展中，不断的被众多学者引用和发扬。所以从大量的流行的软件工程书籍中，大家已经详尽的了解到大多的观点，并且有详细的具体实施方法 (恰巧是本书所未列出的)。就如同本书最后一章中讲的，一个很有趣的场面：作者在飞机旅途中，看到邻座正在阅读此书，但直到下飞机，他仍然没有做出作者期望的惊叹的表现。在作者不满足的追问他读后感想时，他说：“书里面所说的观点我都知道！”。作者便放弃了介绍自己的想法！(这可能减少某些人有意攻击本书观点的欲望，另一方面也是作者本书的意图) 中文版：编排者有意维持作者/原出版商的设计思路，但只学到其表面。(恰巧如同本书的意图的另一面) 太厚，〈〈生存手册〉〉500页比他还薄1/5。 装订有问题：每页空白留足，无可厚非，但相对的字体太小，过于靠近装订线处，加上书过厚，读起来甚累！！(软玉生香, 从形体上变了) 小字体推荐〈〈Software Architecture--Perspectives on an Emerging Discipline〉〉, 250页，只有它1/4 厚度--小巧玲珑！ zglcl008 当你负责过几个项目的开发后在评论本书是否有用吧，别作无畏之争了。参加过大的项目的开发，无论你是程序员还是项目、计划、测试、进度、质量的管理人员，如果你对书中的有些观点还是无动于终，那你还是缺乏总结与思考的。无论对与错，适用不适用要多想想借鉴而已。 jiseng 书不错，就是32开太小，不太习惯，而且俺上班看的时候被领导K了一顿，说俺上班时间看小说，:'( 没办法，难怪领导会搞错，哪有科技书起个这名字的..."XX神话",书还没读完，读完后给大家汇报情况... swachian 不错的散文书, 译的也很有可读性. 第一次就印2万册, 可见其面向读者面之广了. mah-jong 平心而论，书是好书。但如果指望从这本书里找出解决开发中面临的软件工程问题似乎不太可能。这本书的意义从我的角度来看有两个，第一个是作者用通俗易懂的笔法写出了一些常识。第二个是没有银弹那篇文章的观点，就是解决开发过程中问题的万能药是不存在的。我们都知道，很多软件从业人员对自己的工作有着类似宗教的感情，有时候这种感情会导致管理者和开发者产生“人有多大胆，地有多大产”的错觉，从而忽略了常识。这对于工程来说是一件很不好的事情。这本书和其他几本类似的书（比如死亡之旅）类似于解毒药，可以让我们比较冷静的去看待软件开发。 书是好书，虽然我已经看过其中的大多数文章，但还是打算买一本中文本来看看，当作是小说读读也未尝不可。我猜作者的写作目的也不是宣传什么万能药，而是期望告诉读者，一些做法解决不了问题，而另一些做法会让事情变得更糟。 xdsmile 昨天china-pub送来的，一口气读了快一半了。同我以往见过的任何软件工程与开发管理的书籍不同，这本书几乎没有任何软件工程上的规范讨论之类，所有的观点都是作者实践中总结出来的，而且也不套用软件工程的原则，而是自己起名，自己定义其含意，行文幽默；最重要的是作者并不强调应该干什么，而是提出问题，提出解决方案，提出适用范围，提出其方法的局限性，指出在他的实践中是怎么用的，产生了什么后果，并总结其教训。类似此类的观点在本书中比比皆是，有很多发人深醒的论点。20年前的这本书称其为经典的确名副其实，看完这本书，我想就不难理解为什么美国的信息产业有如此巨大的实力了。 另外，不得不说的是必须得感谢译者，从译文的字里行间可以看出其中的辛苦，看出译者所花费的心血和努力，尤其是每章的标题，翻译的尤其贴近中国文化的内涵。 还有，呵呵，就是其低廉的价格，在这个名字就是金钱的年代，如此的好书才不到30大洋，真是令大家跌破眼镜。较之某些××××就上百的书来讲，其中的性价比可想而知，感谢为这本书出版而努力的人们。 play hehe 有道理。 我喜欢看老外的书，因为他们组织书的内容的结构本身，以及行文过程中体现出来的是个人的思维。看的是他们的思维过程和思路，而不是得出什么什么结论。 因为，谁也无法说什么样的结论就是好的，什么样的结论就一定不正确。所以，国内很多书我一般只是拿来当作手册，而国外有些书，虽然他们写的内容和我们的环境可能有很大差异，但从他们的思维过程和发展过程本身，有很多东西值得学习，和琢磨。 望国内也多出一些值得推敲，甚至能引起大家争论的好书。共勉！ xdsmile 看来这本书引发了大家的许多争论，其实对于书籍是仁者见仁，智者见智的；有个小故事，在英国的一列火车上，有个人正在看书，旁边一位老者看他那么专心，好奇的问他在看什么书？那人说在看霍金的《时间简史》，并说自己很久没看到这么有趣的书了，那个老者听了说：“哦，是那本书呀，我看了几遍都看不懂”，那人很奇怪，说：“不会吧？我觉的很容易懂呀，没什么难的，我是个商人，很少看书的，都能看懂”，老者笑了笑，没再说话。后来才知道，那位老者是苏联科学院的资深院士。 从这个小故事，我们其实就可以看出，一本书对于任何人，其体会是不同的。 比如，我在书店看了《计算机程序设计艺术》，觉的太枯燥了，根本不想看，可我知道那是套好书，它并不会因为我看不懂就没有其价值。 imhexi 看了前面的几节样章，一直期待出版。哈，终于出来了，上来买先！ 感觉很不错，比较实用，还有很难得的一点就是行文通俗，在软件工程的书籍里面比较罕见。 ricky 我买了一本，请大家告诉我哪一块写得好可以吗，我怎么没有看出来 mah-jong 那些内容写得好是见仁见智的东西。我个人比较喜欢巴比伦塔、另一面以及没有银弹这三部分。刚才出外面办事，顺便到书店里面买了一本中文本，九折，价格还不错，呵呵。回来大概翻了翻，译的还可以，不过原书中那种简洁而不乏味的语言风格没有表达出来，可能译者可能过分强调和原文符合，所以表述上有些啰嗦。比如：“我们可以通过遵循优秀的而不是拙劣的实践，来得到良好的设计”（pp239）。“而不是拙劣的”这个词和“，”完全没有必要保留。这本书属于散文性质，不是技术手册，只要不翻译错，怎么让人读起来顺畅就怎么翻好了。 easyso 我现在看到第7章——为什么巴比伦塔会失败？ 下面我补充一些材料，帮助各位，特别是非基督徒理解《圣经·旧约·创世纪》11章1-8节。有一点说明：一般现在都称The Tower of Babel 为巴别塔而不是巴比伦塔。 Part 1of 2 CUV-和合本，Chinese Union Version 1那时，天下人的口音，言语，都是一样。 2他们往东边迁移的时候，在示拿地遇见一片平原，就住在那里。 3他们彼此商量说，来吧，我们要作砖，把砖烧透了。他们就拿砖当石头，又拿石漆当灰泥。 4他们说，来吧，我们要建造一座城和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上。5耶和华降临，要看看世人所建造的城和塔。 6耶和华说，看哪，他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所要作的事就没有不成就的了。 7我们下去，在那里变乱他们的口音，使他们的言语彼此不通。 8于是，耶和华使他们从那里分散在全地上。他们就停工，不造那城了。 TCV-现代中文译本，Today's Chinese Version 巴别塔 1起初天下的人只有一种语言，使用一种话。 2他们在东方一带流浪的时候来到巴比伦平原，在那里定居。 3他们彼此商量：“来吧！我们来做砖头，把砖头烧硬。”于是他们用砖头来建造，又用柏油砌砖。 4他们说：“来吧！我们来建造一座城，城里要有塔，高入云霄，好来显扬我们自己的名，免得我们被分散到世界各地。” 5于是，上主下来，要看看这群人建造的城和塔。 6他说：“他们是同一个民族，讲同一种话；但这只是一个开始，以后他们可以为所欲为了。 7来吧！我们下去搅乱他们的语言，使他们彼此无法沟通。” 8于是上主把他们分散到全世界，他们就停止造城的工程。 gigix 终于看到了第一个有价值的批评。在我看过的圣经版本上写的是“巴别塔”，所以看到Adams用了“巴比伦塔”这个词的时候，我担心他会被人批评。只是没想到，这位真正的批评者来得这么迟，让另一些人跳梁了这么久。 （另：巴别通天塔建造的地方是幼发拉底河与底格里斯河交汇处的一个小村庄，名叫Shinar。我很喜欢这个村庄的名字。） 读者当然有批评的权利，你尽可以使用这种权利。不过，到目前为止，对于人月的批评，只有easyso的批评是打到了点子上，其他的批评者都只是在那边自说自话地叫喊“不好”、“不好”而已。 对于这本书，有很多人说好，并且说出了它好在哪里。而easyso之前那些所谓的“批评者”呢？你们的观点在哪里？你们的论据在哪里？你们知道这本书不好在哪里吗？对于这样一本经典著作，我早就想看看会有怎样的批评，可是这些“批评者”们太让我失望了。 adams_wang 关于“20多年前的书，现在有些地方看得不是很懂，毕竟我对20多年前的技术及软硬件状况不了解”，我想解释一下，书中提到的东西，并不是只存在于20年前才有的硬件开发中。在现在单片机、通讯、嵌入式等开发中，情况基本一致。另外，根据个人经验，该书中的观点同样适用于现在的软件项目开发中。 而谈到软件行业的基本技术，如操作系统理论、数据结构、编程语言、数据库理论基本成型，相应的实践也由先驱们前扑后继，积累了大量的经验。另外，对一般的软件从业人员而言，项目中面对的是社会学的问题，而不仅仅是技术问题。真正的技术突破由那些科学家等人已经完成，甚至推向市场。我们只是应用他们的成果，从这个角度讲，大多数应用软件开发人员只是沉浸在“高科技”的幻想中，所以，软件项目管理中更多的是人的管理，而非一般的技术“突破”问题。如果这方面仍然有理解的难度，个人有些遗憾。 很荣幸能同您就书中观点进行探讨。 Easyso 翻译得不错了，如果能多了解一点圣经和基督教的指示，就可以翻译得炉火纯青了。 ququxiao 我赔！高明的译者多了，有几个象你这样急功近利的，还要开研讨会，更想上新闻联播吧，可惜上不去！ lzj310 我作为项目经理、部门经理或技术负责人有两年时间，一直为书中所提出的问题困扰。感谢你翻译的这本书，她解决了我部分的问题。另外我了解到该如何思考技术管理中出现的问题。 cuixian 书太厚，字太靠中缝，阅读不方便。 mah-jong 再谈《人月神话》的翻译 今天没事，用东北的歇后语来说就是“下雨天打孩子，闲着也是闲着”。再来谈谈《人月神话》的翻译。这几天这里有关人月神话译本的争论我都看了，和一般的论坛相比，这里有着一种难得的幽默感。正方观点说嫌翻译的不好你自己来呀，还有巴比伦塔的翻译是致命的问题，其他问题是没有的。反方的观点是翻译的不好就不该翻译名著，译者和出版商拿着这么个译本就召开讨论会有点恬不知耻。从我这种普通读者眼里来看，无论是正方还是反方都是些极有幽默感的人，实在是佩服得不得了。先来谈谈正方的观点。 正方的观点一类似于食客挑剔厨师的菜，厨师一怒之下说你来炒好了。我猜这世上绝大多数饭馆都不会做这种事情，这是砸自己的饭碗嘛。同样的，作为读者付了钱买书，觉得翻译的好就叫声好，觉得有问题就说说。当然，如果不喜欢，译者可以让读者闭嘴。读者也可以不谈，但从长远来看，这种做法是在砸出版社的招牌、汪先生的招牌和UMLChina的招牌。当然，如果诸位说我就干的是这一锤子买卖，以后怎么样我不管，那我也无话可说。翻译和出版社出书是为了赚钱，但对于读者来说这是件好事情，语言文化的差异、国内的外汇管制制度和收入偏低，让大多数读者不能很幸运的去买自己想看的原版书，而有人来做这种经典书籍的翻译工作，出版社和翻译者得到了收入、读者得到了想看的书，无论对那一方都是有利的事情。在可以预见的时间里，这种事情还是比较好的。利人利己的事情为什么不好好做呢？ 正方的观点二是认为巴比伦塔这类翻译才是问题，其他问题不是问题。那我就想知道了，我前面举的那个句子您认为很流畅吗？这种句子在这本书里比比皆是，再举一例，又是随手翻到的（pp62）,“面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法来挑战估算的结果”。当然，这些句子不能说是错译，还是表达出了作者的意思，但您觉得这种翻译符合中国人的语言习惯吗？容易理解吗？当然，兄弟资质愚钝，可能对这种深奥的东西理解不了。但我读原文的时候可没有这种感觉，作者的写作让我这种E文很烂的人都可以读得明白晓畅。还有前面说的那个“可爱”的问题，我怎么就没看出来有什么可爱的地方呢？所以，我说译者没有把作者原文的那种清晰简洁的风格表现出来。当然，如果正方认为这种译文没有什么问题，我只能怪我自己，中学怎么没有好好上语文课呢？对这么简单的句子都认为不够清晰，对这么“可爱”的事情都没看出可爱来。 现在再来谈谈反方的观点。我觉得用不着无事生非。首先出版书是要赚钱的，总得造造声势。这没什么可指责的，而且这本书确实是好书，多做做宣传也是件好事嘛。再有就是翻译资格的问题，这不是什么大问题，经典也是人写的（人是人他妈生的，妖是妖他妈生的，呵呵），而且这本书翻译的还可以，比起大量的句子都没翻译通的书还是好多了。再说了，这个译本老兄不喜欢可是等更好的译本出来再买嘛。 最后再来谈谈我自己的观点，如果用10分制来评价，这本书的选题还是非常好的，可以给10分。翻译的还可以，可以给7分。版面设计可以给9分，和原书的风格很接近，可惜封面差了点，所以扣了1分（里面的插图虽然不太清晰，但考虑到这个价格，也就不必扣分了）。期望译者的下一本书可以翻译的更好些（如果汪先生还做这件事情的话）。 就这么多，顺便补充一句，我现在有点怀疑正方和反方都是出版商的托，为了搞出一个热烈的气氛，让我这种傻不机机的普通读者关注这本书并掏腰包。我觉得没有必要这么做吧，想买这本书的人，肯定会买的，再说汪先生翻的还可以。 xtall 这才是有价值的批评。 mah-jong,你不会也是托吧？让我这种傻不机机的普通读者关注这本书并掏腰包。 mah-jong 我倒是挺想做托的，可惜还没有这个机会，呵呵。我愿意谈这本书倒不是因为我付钱了，主要是因为这本书的风格一直是我欣赏的，还有什么麦克康吉尔写的软件工程不是科学丫，Yourdon的死亡之旅之类。这些读物对于个人的具体工作没有太强的指导作用，但从一般意义上来读非常开阔思路，还是很有帮助的。 对于译著通常我没有太高的要求，反正我的英文应付技术书还不成问题，而且也有自己找原版书的渠道。买些译著来看也不是想给人挑毛病，而是觉得母语的东西亲切些。翻译的好，我就放在手边，翻译得不好，就翻翻丢到阴山背后。 fhlix 排版太e了！ 明明可以印成小册子，随身携带着看，却搞得臃肿不堪，有凑页数的嫌疑。不知道什么时候有影印版 easyso 巴比伦和巴别的区别可是比较大的，查金山词霸关于Babylon和Babel的解释，主要有： Babylon: 巴比伦式的城市指奢华糜烂的城市或地区，经常是罪恶和腐败的； 巴比伦, 奢华淫靡的城市, 任何大的富庶的或罪恶的城市。 巴比伦古巴比伦王国的首都，位于幼发拉底河沿岸的美索不达米亚境内，作为首都大约建于 公元前1750年，在它被亚述人毁灭后（ 公元前689年），它又被尼布甲尼撒二世重建于王室显赫之时，巴比伦是世界七大奇观之一的空中花园所在地。 总结，Babylon的含义是关于罪恶，与Sodom、Gomorrah 是比较类似的词； 而Babel，巴别在《旧约全书》中希纳的一个城市（现在被认为是巴比伦），当建筑者们不能理解彼此之间的语言时，通天塔建筑被迫中断了； 【圣】(古巴比伦人建筑未成的)通天塔(上帝因他们狂妄, 责罚他们各操不同的语言, 彼此不相了解, 结果该塔无法完成。见旧约创世纪。) [babel ][喻]摩天楼; 难以实现的计划 [babel ](意见等)不一致; 杂乱声 n. 混乱，嘈杂 n.空想的计划 总结：Babel有难以实现、混乱、嘈杂之意。 mah-jong 大哥，你可真幽默。当然，这个词翻译确实有点小问题，但这不妨碍理解作者的意思。作者和译者把圣经的上下文都放在那里了，我想，任何人只要读了，都可以理解作者的意思，而作为译者，能够表达出作者的意思也就够了。译者犯的这个错误其实无伤大雅（我倒不认为这是错误，只是编辑的疏漏罢了），再说也不是没有巴比伦塔的这种译法，老兄这可是鸡蛋里面挑骨头。如果不信，可以用google搜索“巴比伦塔”和“圣经”这两个词。 至于给译者挑毛病，只是希望译者能够做得更好些。这本书的翻译，我只能说没有明显的错译。看得出来，译者是下了功夫的，我随手翻到的几页至少没有不通的地方，但只限于此。译者的中文表述上需要继续加工，比如我前面举的那个例子，我再顺手举个例子，是随手翻到一页（未加选择的翻，pp77），“对软件系统的体系结构师而言，存在一种更加可爱的方法来传播和推行定义”。“可爱”？！确实挺可爱的，呵呵。 出版社把书稿交给译者，译者再转包给学校里面的学生，这是公开的秘密，也无所谓对错。可是读者总能要求出版社和接书稿的人细心一点吧。 cat_hangzhou 很遗憾还不能看到书。看了样章...感觉不错。 其实对一个真正的程序员来说，翻译...至少我感觉不是太重要...能让我看懂就可以了。也许译者不是很专业，因此一些概念没有用术语表示...但是名词无非是一种指代，偶看这种书的时候，就当做宏处理掉了：） 就象骂名已久的TIJ第一版，呵呵，开始看有点累,但是明白了译者的习惯了以后，也能看下去啊。 当然了，侯老师译本更好，偶是当看小说一样看完的...呵呵，侯老师不要生气：） 其实老外的书...和国内的思路不同。对他们来说，他们很愿意将自己的想法用一种简单的方式表述...就想曼昆的经济学。 功力不到，反而在怪老师讲得不好...有一点点的过分。 译者很辛苦，因为西方有很多成语、典故，不见得所有的人都知道...就象巴比伦塔。好的翻译，很可能就会带上厚厚的注释（尤利西斯）。但是不能这样要求每个翻译。也许对他来讲，他认为这些是人所共知的。 就翻译来说，我的观点：第一要准确，不要扭曲了作者的意思；第二就是要明白，不要出现很拗口的话。呵呵，《设计模式》这本书，我打开来很多次，但是每次都看不下去...看不懂...我不敢说译者的水平如何，只是觉得自己的火候还不到。 读书...很多时候是一种相互交流的过程...我已经在考虑这方面的问题，恰好有这样一本书，可以帮我解惑。如果我对这一领域根本没有涉足，那么我想作者译者的水平再高，与我来讲也不过是对牛弹琴，而我自己的感觉是味同嚼蜡（就象我看生物技术的书一样） 人月神话，本来就不是一本纯技术的书。也不是管理的书。这本书只是一些经验的积累。我在带项目，感觉就是很累，有很多问题不知道怎么解决。很希望在这本书里能够得到灵感。是的，我只希望得到灵感，并不指望得到答案。 关于有人提到的20年的技术...我想不用争论什么。如果要争论，那么首先要争论的是什么是技术！做程序时间不久，水平也不高，但是我一直认为，对一个项目（工程）来说，重要的不是采用什么技术，而是思想！如果程序员还是停留在具体一段代码一个方法的争论中...那么也许你可能成为一个很资深的程序员，但是永远成为不了可以高屋建瓴的程序员/项目经理。 很感谢译者能把这本书带进国内...很希望能够看到有新鲜的思想。呵呵，至少是对我而言。 中国的教育是填鸭式的教育。很希望大家能不做养殖场的鸭子，而是做只野鸭。 我决不指望译者能按照我的口味来翻译，我会努力尝试去适应译者的口味。毕竟，是我需要看，而不是译者。 最后，如果能通过漫画、小说让我明白其中的道理、思想，我会很感激。但是我知道这个，基本上不可能。于是，退而求其次，至少，说明白问题。：） 呵呵，没看过全书，不好评价。仅从样章上看，译者还是有一点中国文化的功底的。打星...实在不好打，因为我怕样章是全书唯一翻译的好的：）但是就凭那一个样章，我认为全书也值三颗星了：） yusc_ww 没看书就有这么多废话，I服了u cat_hangzhou 呵呵，很不好意思...污了您老法眼。 书...我昨晚看掉了一半...说实话，看起来很顺，但是没觉得融会贯通。 另外，废话并不是针对这本书的，而是有感于不少无谓的争论。 嘿嘿，看了一半，感觉...废话至少不是错话：） 自己的...既然是废话，那么给个鸡蛋吧 wlcun 在校大学生注意了，去你们的图书馆找一本《论大型软件的开发》，武汉大学出版，1.10元，如果你找到，你会发现就是《人月神话》，新版本也只是“增加了一些新的想法和建议”（作者语），我发现以前出版了不少经典好书啊，版面设计精致，略发黄的书页让人爱不惜手，如果你想收藏，就给清华面子，要不以十倍价钱赔给图书馆（我就这样干了）。最后一句：现在的书价太黑，把上china-pub的一半时间去泡图书馆吧。 我向来对价钱不是太看重,一些好书你定价高点无可厚非,但清华的人月让我看到清华极其丑陋的一面，这书的旧版是武大老师70年代翻译的《论大型软件的开发》，才rmb一元多，因为这书本来就比较薄，清华的书字大行疏，留白空间可用变态形容，一张小插图用图文环绕的方式挺好，清华偏放大数倍单独一页显示，清晰度下降。书搞得太厚翻阅不便，唯一的好处是能锻炼前臂肌肉。大伙去图书馆把武大版的找出来看看，就知道清华有多恶心，把“散文”当“小说”印的出版社问世间也只有它了，当然，处心积虑也最终为了定价。我本来想收藏一本的，由于极度影响阅读我放弃了，陪了十倍价钱给图书馆拿了本武大的，如获珍宝。 liuty2006 大概翻了一下。没什么价值---至少对于我。二十年前的书,对于突飞猛进的计算机技术来说,的确老点。 Thecleverestman 正确的思想永不落后 ggggwan 昨天去海图买了这本书，回家看后的感觉是有点失望，总的感觉是这本书不如微软那本《快速软件开发》好，不知道是翻译的原因还是原文的原因，读起来不是很流畅，没有那种让我看完后有酣畅淋漓的感觉，看过的软工书只有快速软件开发让我有这种感觉。也可能是文中有很多观点在其他的软工类书中也都有介绍了，看过后没有那种比较震撼的感觉。 另外，文中对软工中的问题缺乏实例讲解以及如何解决的论述，比较泛泛，不容易抓住要点。最近做的一个项目，集成了很多IBM的软件，看IBM的文档经常就会给我这种感觉，说了很多东西，但是我需要的或者认为重要却说的不多，而且经常写出一些让人看后费解的话，不如微软的文档傻瓜，搞的我很是头大。作者是IBM出身的，是不是传染病？ 还有书的大小采用了32开，搞的页码比较多，翻起来很难受，不如小16开的好，留白太多（虽然序言中说明了这是anders wesley出版社编辑的决定，但是我觉得不爽，因为我不认为有什么必要在书边做笔记），虽然我买书可以报销，但是留白多总是让人感觉好像花25块钱享受的却只是20块钱的服务。 gemlei 浮躁的UMLChina从来就没有自己的观点，那着外人的成果标榜自己的权威。“人月神话”是一本能误导初学者的好书，你可以说它的预言是诡辩，因为没有详细的统计数据和深入的项目背景解剖。泛泛而谈，包容万物。 因为它想什么都是，所以它什么都不是。阅读“人月神话”每个章节像是在做一道道“辨错”题，在项目不同的背景，资金，人员素质，盈利模式下，有着不同的答案。感觉是在学习CMM后一个用于练习的案例，仅此而已 hyqzmy 很好的《人月神话》怎么会翻译成这样？试讨论一二 鄙人以前看《人月神话》英文版，毕竟功底不够，看得慢而无趣。前不久无意之中看到中文版译出，更兼翻译者简历赫赫，急急搜购一本，意图一快，不料读了几章，一些意见却是不吐不快了。 众所周知中文贵在简洁，美在简洁，翻译起来很少会出现译文比原文长的情况，可是看看几个小例子： 第四章“贵族专制、民主政治和系统设计”，原文为“Aristocracy, Democracy, and System Design”。纵使Brooks老先生是隐喻大师，我在文中也没有看出一些“贵族”气来，“政治”意味也几乎没有，莫非译者喜欢用搞政治的办法来搞软件？鄙人看来，“专制、民主与系统设计”已经足矣，要更贴切地表达Aristocracy,则可以用“精英制、民主制与系统设计”。 这个问题实际不大，到了第五章我实在就忍不住要来写帖子了。这章名为“The Second-System Effect”，被译为“画蛇添足”，具体文中遇到这个词组时，又被翻译为“开发第二次所引起的后果”或者“开发第二个系统所引起的后果”。天哪！这里显然Effect直接做“效应”译就完了，文中讨论的后果大部分也并非“画蛇添足”，而是在开发升级版本的产品期间常见的一些误区的讨论。我不知道译者是否熟悉软件开发的版本习惯和硬件/系统产品的系列化升级编号习惯，但是从全章描述的内容看，直译的“第二系统效应”甚至更简单一点称为“V2效应”，恐怕都比什么“画蛇添足”、“开发第二次所引起的后果”或者“开发第二个系统所引起的后果”来的准确而没有歧义与误导。 限于时间，我不再一一举例讨论了。有心的读者朋友不妨在阅读期间自己对对书上提供的原文。看得出来汪先生在翻译中花费了很大的心力，专注与投入是毫无疑问的。汪先生简历赫赫。应该也属青年才俊之流。可是为什么我们计算机专业的外文经典一翻译过来往往就错漏百出呢？如果这样，如何相信这批人马做出来的软件可靠呢？ 据说软件业界有个最佳实践叫做“同行评审”。这本书出版卖钱之前，我看到了同行吹捧，同行评审又有没有呢？那么一大批的编委会，莫非竟是一张虎皮么？ Gigix 有这么严重么？ Aristocracy和Democracy这两个词，是来自于亚里士多德的政治学说。亚里士多德认为，“良好的”政治体制有三种：君主制、贵族制和民主制。这两个词就是这三种政治体制的后两种。所以，如果你问我这个标题有没有“贵族味”和“政治味”，我就觉得它有。当然，你翻译的“精英制、民主制与系统设计”也不错。不过我觉得，最多只能算难分伯仲。如果要说谁更准确地译出了Brooks引用亚里士多德的味道，我倒觉得Adams的翻译似乎更好一些。 至于你提出的第二个问题，我更觉得无意义了。“程序员在第二次开发类似的项目时加入一些不必要的特性”，这样的行为用“画蛇添足”来描述不正是很贴切吗？至于你所提出的“V2效应”，恐怕更多的人会想到希特勒的远程导弹，而不是“软件的第二个版本”。看来，这个翻译顶多也只能算难分伯仲了。 中文是不是“贵在简洁美在简洁”，或可商榷；是不是要“翻译起来很少会出现译文比原文长的情况”仍然或可商榷。比起刻意追求“简洁”，想来还是易读性更加重要。“公共汽车”这个词，在英文中只有3个字母、1个音节，请问你要如何追求“简洁”的翻译？ Hxtan 翻译得确实不错 这本书翻译得确实不错，但仍有一些瑕疵，例如： 1、“的地得”偶有混乱。这常常是我判断一个人中文表达是否规范的重要标准。 2、有的术语译得不够到位。例如，将 "An Integrated Approach" 译成了“一条完整的路”。 yuhai 昨天拿到了书,还没有仔细看. 书的内容暂且不说,只是感觉印刷(或装订?)不是很满意,字太靠近书脊,看得时候比较费劲,要用点力气把书摊平才行。书的行距和间距比平常的要大,大约23*24吧,不知道是不是为了多印几页好提高定价? 总之在不了解内容的情况下,单看印刷情况我是没有购买的兴趣的. gbhome 终于拿到了这本《神秘的人月》，嗯。一本多年来看到被无数的工程、实践著作引用的文献，终于乖乖地躺在了我的手心里。 第一件事就是把中国人写的那些页数，统统裁下来扔进垃圾筒，本来中文的表达力已经限制了我们对全书的理解，请不要再让那些什么UMLChina之类的废话把整本书的导向都弄错了吧！在《神秘的人月》诞生的时候，别说UML，连C++都还没有呢。什么印度，呵呵，印度注定要失败的。 不过客观地说，翻译的水平虽然没有我期望的那么高，但居然也不像我想像得那么差。总体而言，还算差强人意。排版不错，我喜欢这种小开本的书，封面也不错。如果是裘宗燕老师来翻译，一定又是一本旷世译作。 对于软件工程我当然有自己的看法，但是我不像许多中国人，在译作前大谈一番，好像比作者还牛。我们没有资格这么做，人要知廉耻。对于这样一本书，在得不到英文原著的情况下，我们要透过中文的表象，来虚心地看每一个字。已经一个星期了，我还在看《焦油坑》这一章，做了几十页的笔记。 无论如何，清华大学此番引入这本书，也算了了我多年的心愿，感恩不尽。 homerlu 多谢这位老兄。我还真不懂那段鬼文。 我说它怎么不用鬼话呢。原来自己中文水平有限。 第一、此书书名翻译成《人月神话》比《神秘的人月》要强，不要告诉我你不明白mythical的意思。从内容上看，人月没什么神密的地方，这是一个在软件行业还是比较流行的，当然流行并不表示它的正确。所以说它仅仅是一个神话，一个实现运作起来类似理想状态的神话。这远比所谓的“神秘的人月”要好的多。自以为自己水平有多高，“中文的表达力已经限制了我们对全书的理解”，就看你的书名翻译我要怕你的理解能力对你有所误导才是真的。能看的懂译作算你可以运气了。 第二、“在《神秘的人月》诞生的时候，别说UML，连C++都还没有呢。”没想到还会有如此的逻辑，诞生早能说明什么？照着种逻辑似乎你爸三个月大小的时候比你现在懂的都多？毕竟早诞生了，那时还没你呢。何况现在的你。《人月神话》（目前书名如此）作为杰作不是因为它诞生的早于UML,C++。这点道理你也不懂，还在这里摆谱，可笑！ 三、“什么印度，呵呵，印度注定要失败的。”失败大家都会遇到，谁能保证永远成功，一天，一年，一个世纪，...你能吗？所谓的成功只能说是阶段成功。从这方面说印度毕竟取得了它的阶段成功，它如果想继续成功下去，自然不是现在的状态，或许要改变政策才行，他们的政策成功便成功，政策不成功便不成。那是你能预见的到的吗？ 四、“已经一个星期了，我还在看《焦油坑》这一章，做了几十页的笔记。 ”我不得不说你理解能力有限了，焦油坑那7页多的书只是书中的一部分，后面还有很多精采内容。不要“只见树木，不见森林”。感觉你真的掉到焦油坑了：）相信此书的主旨不会是让大家拿“几十页的笔记”研究7页的问题，如果需要的话，相信作者会写几十页而不是7页的。当然，但愿“几十页的笔记”。能帮你理解那7页多的焦油坑。不过也好，有一天一页的速度，坚持一年也能看完，希望你能坚持下来。 五、“但是我不像许多中国人，在译作前大谈一番，好像比作者还牛。我们没有资格这么做，人要知廉耻。”从这里真看不到你知什么廉耻，原话换一下“所谓你你这少数中国人（这有点阶级斗争的味道）在译作大谈一番，好想比译者还牛”，真是知廉耻了啊，你牛你翻译几本出来让我们瞻仰一下啊，我们对你的。。。如滔滔江水 另外，...同事骂我了，本还想说你乱拽外文、鲁迅、以及对人工作的起码应该尊重问题。可同事说的有道理：“有空啊，又没人给你教育费、监护费，管些闲事”。真是有道理，我就不再多罗嗦了。兄弟，建议你去垃圾桶把你撕掉的页找回来，伸直压平，仔细读读吧。 gbhome 无论你个人对我个人是什么态度，这无关紧要，homerlu先生／小姐给我的批评指教我无条件地接受。有则改之，无则加冕。 人们之间需要理解，我说中文限制了表达力，这并没有错，因为原著是英文，译成中文要打折扣。 用德文写那段话，是因为正好买了一个德语键盘，写了一个驱动，没有事情做。 homerlu先生／小姐，也许您是专家，可是我开始搞计算机的时候，你还不知道在做什么。你的薪水可能还没有我的零头那么多，首先管好自己，这一点很重要。人各有志嘛，争什么呢？我感到无谓。 说印度注定要失败，并不是我的话，是Bjarne Stroustrup的原话，大概你总没有资本说这位元老吧。 把《The Mythical Man-month》译成“神秘的人月”，是裘宗燕老师在《程序设计实践》中的处理，我只是照样说出而已。您的资格，也不可能比裘老师好，这一点我倒是深信。说实话，我如果和homerlu您比英文，您可能会自惭得跳楼。 我做笔记，是我的求学的态度，虽然笨一点，比那些声称看过多少书，实际上什么也没有看到心里去的人要强不知道多少。 Len Zhong 这本书我期盼了很久了，大家我想也是一样；但是书打开后，个人的感觉是不一样的。我先说说我的感觉，这本书很亲切，好像回到10多年前程序开发的日子，虽然，有些理论和技术对现在来讲有点陈旧，但是在27年前就有如此深邃的看法， 我佩服的五体投地 边看，我边回忆，边体会，虽然很多的理论和经验，我都已经很熟悉了，但是重新体验，果然回味无穷。作者背后深厚的观察力和思考力，思维方式都是值得我们学习的，如果有了此等功力，不难出一个中国版的“人月神话“.对我来说，这一本书绝对值的收藏的。 对于翻译， 我觉得作者是非常严肃，认真的，行文也很流畅，对很多都进行的认真的考究，值得表扬，虽然有小小的错误，但无伤大雅。 唯一不足的，是印刷比较差，书太厚，太重了，看书的时候，手都拿酸了 huangyz 书绝对经典，对软件开发很有启发，我在15年前武汉大学求学时，已拜读（75年初版本），是武大的老师翻译的中文，此书我至今仍珍藏在身边。巴比伦塔、外科小组的比喻至今印象深刻。民主与专制、画蛇舔足等问题仍是软件开发中的常见问题。20周年版我一定会买，只是有点胆心翻译的质量。有谁是否能评论一下翻译的质量？ tjuwayne 原著的价值当然毋庸置疑，译者也是专业水平相当高，而且态度严谨，令人赞许（当然，我不配这么夸奖译者，而是该说“崇拜崇拜”）。 美中不足的是（仅为个人习惯），尽管译作在语句含义上并没有走样，但是有的地方表达得并不符合一般人的习惯，也经不起语法上的严格推敲。我看《自适应软件开发》的译者除了专家之外，还有一位文科生，大概是负责润色工作吧。这样的搭配很好，就是希望别太拽文了，过犹不及。 还有一点，就是译者严格地按照原著把某些词用黑体字来强调，但是这些词译过来后意思并不明显，不如干脆把作者要强调的那句话印成黑体字。 附带一提，我在本书中竟没发现任何错字，尽管单凭这点不能说明本书的价值高，但说明了译者和评审者一丝不苟的态度。 stanleylei 昨天我刚买了书，书的包装我觉得还不错，但是如果能够重新排版一下，降低一下厚度就会更完美了：）只来得及看两章，但是就这前面的一部分也觉得很有道理。以前也曾做过项目，也曾主持过项目，至少书中所说的程序员的感受也让我经历过，而且对于进度与人员的安排上确实是出现过这样的问题。我会继续刊下去，相信会有很多收获：） tianchin 我认为译者谈利益没有什么不好，关键看他是否有资格去谈，这里说候哥不谈利可能是议论的人高估了自己的判断能力，他 不谈利就没有米饭钱去翻译下一本书，关键是他可以追求完美，虽然我不太读他的书。作品在两种语境里面翻译还能 保存原味的说实在还没有出现过，包括钱钟书的译文。所以这里谈是否忠实原文，岂非缘木求鱼？ 只是为了满足 更多专情此道而无外文能力的兄弟而已，仅此而已，目的如此也不必苛求，不知这个说法能够得多少赞同。 对于会外文的兄弟，自然读外文是首选，甚至推荐不要读译文，我深有体会，每每两语对照总有哑然失笑的时候，或叹气，其实这是庸人自扰，译文原本就不能够提供这些。 要在腊肉里面尝新鲜，谈何容易！！ I with the english version come out earlier !! hunsarah123 我觉得这本书中有一些东东的确是有点过时。我想，如果我生活在作者的年代，我绝到不了他的境界。但作者的一些论点和管理技术上的做法，不太适合现在了。我们不能将技术和管理方法截然分开，两者相辅相成。在计算机界讲经典本身就有一点逻辑问题。 我也等这书等了好久了，但是说实话，我有点失望。还不如翻翻cmm标准之类的书更能有点感触。 我不是全盘否定，我也承认这本书有40%的东西是有价值的，但加上时间这个变量后，情况已然和20年前不同了。 charon 这本书的装订是我所见过的书里面最差的。使我连细翻的欲望都没有(本来倒想买一本收藏的)。 首先，内页边缘留空太多，直接导致内文向中间缩，要看内容必须把书摊得很开。现时国内的人看这种非直接技术类书籍，应当没有写附注的习惯吧，所以这种页边留白似乎没有必要。 其次，书很厚，但是感觉不结实。很担心以这种内文版列方式，如果每次都要用力摊开，看到1/4就会散成几部分。 最后选择，如果出于藏书目的，现在不买。也许下几刷会有好转。 brucesea 刚随便翻了一下第四章，两处翻译，讨论一下。 1.P53“结构师...专门来告诉可怜的实现人员如何工作？”“如何工作”？how to do？结构师不应该是告诉工作人员what to do的吗？how to do不应该是实现人员自己考虑的事情吗？ 2.P54 "System/360 Model 30预算上的限制，完全获益于Model 75的体系结构"，Model 30和Model 75谁先谁后，30怎么会获益于75呢？是be beneficial from还是be beneficial for？ 中文版阅读真可谓“雾里看花，水中望月”呀！ 就不提翻译有问题的句子了，意思翻译的没有错误的句子读起来也总是感觉很别扭，很难把握某句话的重点在说什么，再翻翻英文版才恍然大悟，原来作者在强调这个。 duyanning 内容不错,不过有点过度翻译的嫌疑,second system effect-〉画蛇添足,真的是画蛇添足了,不过我还是很喜欢这本书. morpheus 我觉得有人翻译就可以了。其实看翻译过的书，是要有个人第二次翻译的水平的，本人就可以在他人翻译得乱七八糟的情况下反编译其愿意 liuty2006 又一本〈学习的革命〉!!! chengr2000 我是在校学生，没有项目经验， 可是看了这本书后也有很多心得。 可惜只看了3/4，然后送给我姐了. 她现在是一个subleader，比我更需要这本书。 准备过几天再去买一本。 至于翻译，我认为还是不错的， 看了看有英汉对照的部分， 基本上都还表达了原文的意思。 xdsmile 看来这本书引发了大家的许多争论，其实对于书籍是仁者见仁，智者见智的；有个小故事，在英国的一列火车上，有个人正在看书，旁边一位老者看他那么专心，好奇的问他在看什么书？那人说在看霍金的《时间简史》，并说自己很久没看到这么有趣的书了，那个老者听了说：“哦，是那本书呀，我看了几遍都看不懂”，那人很奇怪，说：“不会吧？我觉的很容易懂呀，没什么难的，我是个商人，很少看书的，都能看懂”，老者笑了笑，没再说话。后来才知道，那位老者是苏联科学院的资深院士。 从这个小故事，我们其实就可以看出，一本书对于任何人，其体会是不同的。比如，我在书店看了《计算机程序设计艺术》，觉的太枯燥了，根本不想看，可我知道那是套好书，它并不会因为我看不懂就没有其价值。 msdeng 这本书我不想评论译者，好的译书本能就应该淡化译者，文学书也许不一样，当然我并不是说这个书翻译的就没有缺点，只是我觉得不会影响我理解brooks的意思。 任何书籍不要期望它的每一句话都会直接为我们的工资增加砝码，70年代的书更不要用时尚的眼光来窥视。很显然有的章节，像文档、配置管理你可能觉得这些都理所当然，现在理论和工具都很成熟。但是“焦油坑”在今天不存在嘛？“外科手术队伍”的分工我相信比现在那些鼓吹“软件工厂”进行不讲人性的垂直分工（程序员、设计员、分析员、测试员单独分组）更有效。 有的读者包括中国的软件开发人员实际上也在期望有“银弹”一样的东西，来了“rup”软件工程言必谈“rup”，当听人说"rup"是一个大箩筐，难以使用，又觉得rup一钱不值；当人邮引进"xp"系列后，看了的读者又觉得一个好的系统前面肯定不能做太多设计（前置设计），唯有refactor，但brooks会问你当项目规模10000倍xp的项目时该怎么办？ 这一两年“use case”俨然成了需求的代名称，出版社也投其所好，除了use case的书，基本上很难找到其他需求方法的书，但事实上有多少人真正使用好了use case，知不知道哪些场景适合，哪些情况不适合，use case的优点和缺点，还有没有其他方法？出版社没有立场，我们也没有了判断力。不知道除了xp,还有更多的敏捷方法（像fdd），除了use case还有srs,feature,甚至xp的use story也是，brooks在ibm 360开发中使用规约我想也是一种有效的方法。 比较国内那些不负责任的XXX工作室（像飞思的烂书〈除了最近那本《java与模式》〉）出的书，大部分引进的书我觉得还是很有价值的，读者可以根据自己的需要选择、比较，重要的是要“取其精华，去其糟粕”，老祖先的话不要搞忘了。 作为读者，我们要求译者当然有理，但读者也应当有读者的觉悟，善意、诚挚的批评我想译者更容易接受，当然实在是太差，tnnd有时也难以控制，但不应当是每天几次的例行公事。不过对《人月神话》的炒作也让我有点恶心，作者既然说“no silver bullet”，当然这本书也不是。 当我期望看到对一本书的有价值的评价好帮助我决定时，可看到的却是满篇的街头对骂，忍不住我想说说，得罪之处各位包涵。 chen_czf 我还没有看完，但是从看完前13章的感觉，我认为时间不饶人，对思想也是。并没有让我有拍案叫绝的心动。很多观点在别人的著作里也有描述，也许等我看完第二遍的时候可能会有别样的感觉。 feynman 这些关于软件开发的管理书，对于开发人员其实不是很重要。这些是给那些项目经理看的。就我读过的这方面的书，其实概括起来就是那么几个简单道理，说出来人人都懂，比如要刺激开发人员的士气，比如要合理安排经度，作好需求分析，防止功能蔓延。。。。，道理很简单，只不过真正做起来就不是那么容易把握了。我一直以为，这些东西不是靠看书学来的，这要靠自己的实践，天分，努力。就好象许多人非常有领导才能，他可能会当总统。但是有的人无论如何也不可能。 Long 《人月神话》过了一遍，有几点印象深刻： 项目经理和体系结构师同为一人的困境，特别是一个体系结构师被合同和其他琐碎事务困扰时的情景； 一般应用和软件系统产品的巨大不同； 概念完整和丰富功能的矛盾； 作者对组件的期望之高。