软件工艺（中文版） (2010 年度畅销榜NO.197 )

会员评价：	评级：(共 10 条) 参与评论
原书名：	Software Craftsmanship
原出版社：
作者：	（美）麦克布林著，熊节译
出版社：	人民邮电出版社
书号：	7115122431 出版日期：2004-5-1 开本： 880*1230 1/32 页码： 240 版次： 2004年5月第1版第1次印刷点击: 19443
所属类别：	软件工程/软件技术→综合
网摘

市场价：￥19.80 会员价：￥8.91

内容简介目录译者序作译者前言封面勘误建议用户评论

本书针对软件开发，提出了一些相当棘手和敏感的问题，并给出了颇具争议性的结论：从一个数百年来一直兴旺发达的系统——工艺学中获得启示，寻找答案。
本书用5个部分共19章的篇幅，系统地阐述作者的观点，并试图回答一直困扰着软件行业的难题——我们应该如何重组软件构造的过程，使其能够如我们所愿地有效运转？第1部分共4章，对传统的观点提出质疑——软件工程真的是解决软件开发问题的灵丹妙药吗？第2部分共2章，这一部分提出了本书的观点，即以软件工艺的视角看待软件开发。第3部分以7章的篇幅，从不同的角度全面地展现了软件工艺理论所带来的主要变化，以及如何实践这个观念。第4部分共3章，对比了软件工艺与软件工程，并为各自适用的范畴重新划定了界限。第5部分共3章，分别讨论软件开发中的权宜之计和长期问题。
本书荣获2002年度Jolt图书大奖。阅读本书，有助于引发读者在软件开发问题上的独立思考，本书适合软件行业的所有从业人员阅读参考。

时隔一年之后，当我再次到AMAZON寻找这本《软件工艺》时，它的评价不知何时已经悄悄地变成了四星半，销售排行也已经到了5,000多名——熟悉AMAZON的读者应该知道，在AMAZON能得到四星半评价的已经是精品好书，四位数的销售排行就更能证明它的品质。可是，一年前看到的批评仍然历历在目：“过时的例子”、“混乱的逻辑”、“东拉西扯不知所云”……当这些尖锐的言辞与“所有软件管理者的必读书目”一类溢美之词并列时，我不得不再次认真地思索：这究竟是一本怎样的书？ Pete McBreen说，这本《软件工艺》是一本“极具煽动性”的著作。而在我看来，用“煽动性”来评价它只嫌太客气，或许“颠覆性”会是一个更贴切的词。自1968年NATO会议以降，软件工程的话语就始终把持着软件业（以及软件学科）的言路。一切的软件问题都不由自主地被归咎于“软件危机”，同样自然地，一切的解决方案都不由自主地被划入“软件工程”的范畴。从记事以来……呃，我是说，从上大学以来，我们的一切讨论都围绕着软件工程展开：这样做是否符合软件工程？如何对软件工程加以改进？企业应该如何开展软件工程？凡此种种。在语词的不断重复与变调之间，“软件工程”逐渐被捧上了神坛，成为一种信仰，并因此失去了它旧有的价值与意义。君不见，即令是软件工程的反对者，也只能说出“我们不要软件工程”这样的话——仍然未脱软件工程的话语霸权。 Pete McBreen是一个极其敏锐的人，并且对语词背后的意蕴有着深刻的体认，这或许与他年少时在英国所受的教育有关吧。他一针见血地指出：软件并不是工程，“软件工程”仅仅是一个多少有些不够贴切的隐喻而已。是的，一个隐喻，正如我们常说的“桌子腿”、“针眼”一样，这是一个深入人心、渗透极广的隐喻。但是，尽管每个人都知道绣花针并没有长眼睛，我们却常常忘记了软件工程作为隐喻的本来身份，真心诚意地把软件作为一种工程来对待了。软件工程的困境与读到这本《软件工艺》时本能的拒斥，殆出于此。钱钟书曾说，反其道以行也是一种模仿。而对于目前软件工程的反对者们，另一个更恰当的比喻是“反转的胶片”——胶片的颜色与照片完全相反，但两者记载的信息却是毫无二致。作为一个真正意义上的颠覆者，Pete McBreen为软件开发找到了另一个隐喻（以及随之而来的另一套语词），那就是本书的标题——软件工艺（software craftsmanship）。对于这套工艺学的语词，我一直有着淡淡的隐忧。在西方，工艺学传统多半与文艺复兴的人本主义联系在一起，而在对现代性的反动中，文艺复兴一直是吸引大众的旗帜。因此，可以想象，“软件工艺”这样一个隐喻对于欧美程序员有着不可抵挡的诱惑。而在中国，“学而优则仕”的传统价值观固有地鄙薄工艺学的实践者，“五四”以降现代性的话语又早已根深蒂固，所以我实在不敢乐观地期望这个译本的读者能够让“软件工艺”的思想畅行无阻。好在Pete McBreen并不是一个太喜欢夸夸其谈的作者，书中的论述虽然大胆，却是有理有据。既然Fred Brooks的“没有银弹”已经深入人心，相信以逻辑思维见长的软件开发者们能够抛开对软件工程的迷信，随作者一道认识软件工程的局限，并由此生发对软件工艺的思索。倘如此，这本书也就算不辱使命了。在你开始正式阅读本书之前，请允许我给你打一针预防针：这本书可能颠覆你浸淫其中数年甚至十年的软件观，所以书中的很多观点可能让你感到出离惊奇甚至出离愤怒。请你不要马上把它扔到墙角去，阅读的过程也就是习惯一种话语方式的过程。当你逐渐习惯软件工艺的话语方式之后，或许能从中找到一些自己需要的东西。为这个译本，我要感谢UMLChina的站长潘加宇，是他把这本书硬塞到我的手上，让我没有与这本精彩的著作失之交臂。我还要感谢我的女友、本书的合译者马姗姗，她优雅的文笔弥补了我言辞的生涩，她的支持与鼓励让我能够在工作之余顺利完成此书的翻译。谢谢你，亲爱的姗姗。最后，希望你能从这本《软件工艺》中找到别样的触动和欣喜——就像我曾经的阅读体验。熊节 2003年8月9日星期六凌晨杭州

用“工艺学”来比喻软件开发，这可以看成是对软件开发的一次追根溯源：优秀的软件开发者们一直都知道，编程的确就是一门工艺技巧。不论软件开发者拥有多少纷繁芜杂晦涩难懂的知识，但最终左右着应用程序开发的仍是那种不可言说的感觉和经验。举个最简单的例子：也许有人能够了解Java语言所有深奥幽暗的技术细节，但除非这个人能培养起自己对于软件的审美感觉，否则他永远无法真正精通应用程序的开发。而与此相反，一旦某个人获得了那种软件开发的感觉，特定的技术细节就变得几乎完全无关紧要了。优秀的开发者总是在不断地学习、使用最新的技术和技巧，对于他来说，学习一门新的技术只是软件开发者生涯中的家常便饭而已。 “软件工程”这个词是由NATO属下的一个研究组在1967年提出的，这个研究组还提议召开一次会议，专门讨论“软件所面临的问题”。1968年，由NATO科学委员会主办的这次会议在德国迦米许*召开，会议提交的报告就被命名为《软件工程》。在这份报告中，Peter Naur和Brian Randell这样写道：“我们之所以选择了‘软件工程’这个颇具争议性的词，是为了暗示这样一种意见：软件的生产有必要建立在某些理论基础和实践指导之上——在工程学的某些成效卓著的分支领域中，这些理论基础和实践指导早已成为了一种传统教义。” 和他们一样，本书之所以选择了这样一个颇具争议性的书名（并提出了很多颇具争议性的观点），是为了暗示这样一种意见：软件开发的实践者们有必要开始关注软件开发的工艺。软件工艺是如此重要，因为它让我们摆脱“制造业”的隐喻（这个隐喻正是软件工程所带来的），并让我们开始关注从事软件开发工作的人。软件工艺带来了另一种隐喻：拥有技术的软件开发者抱定决心要掌握自己所从事的工艺，对自己的劳动成果负责并以之为荣。软件工艺并非与软件工程或者计算机科学针锋相对格格不入。与科学和工程学相比，软件工艺是另一种完全不同的教义，但又能与这两者很好地共存，并从中获益。现代的铁匠能够因为更好的工具、原料和知识而获益；同样，软件工艺也能够因为更好的计算机、可复用的组件和更先进的编程语言而获益。铁匠们在自己的工作中融入了技巧和艺术，从而超越了科学和工程学的范畴；同样，软件工艺能够指导开发者生产出优秀的应用程序及系统，因此也可以超越计算机科学和软件工程学的范畴。对于这一论点，最好的佐证大概就是UNIX和现在的GNU Linux了——这两个系统之所以能够获得如此巨大的成功，完全是因为它们的创建者拥有精巧的手艺、高超的技术和无私的奉献精神。很长时间里，人们一直试图强迫商用软件的开发适应软件工程的要求。这种削足适履的做法引发了不少的问题，而软件工艺则给这些问题带来了答案。软件工程的发展，很大程度上是为了满足NATO成员国开发超大型国防系统的需要。而商用软件的开发与军用系统、政府系统的开发却有着天壤之别：商用软件的规模通常比较小，并且开发时间通常不能超过18个月。只有极少数商用软件是由超过20人的团队所开发的，大多数开发团队都不会超过10人。对于拥有200人以上的大型团队，软件工程能够很好地解决他们所遇到的问题；但对于“团队中的个人应该如何锻炼自己的技艺”这个问题，软件工程却几乎没有任何论述。软件工程鼓励在软件开发中使用人海战术。软件工程不但没有解决“如何培养拥有高超技艺的开发者”这个问题，反而试图降低对软件开发工作的技术要求——软件工程认为：只要投入更多的人手，所有的问题都可以得到解决。这实际上就是在暗示：如果可以拥有大量技术水平较低的开发者，那么我们就不需要那些技术超群的“高手”。尽管人海战术有时能够成功，但最终得到的软件多半也是垃圾：它们多半臃肿迟钝，总是无法令人满意。用户被眩目的图片和动画搞得晕头转向，但就是无法真正掌握软件的用法。由于无力学会使用整个软件，他们会有强烈的挫折感，并只使用很小一部分功能来满足自己的需要，而更多的功能则根本无人问津。软件不一定非得要像这样的。我时常看到这样的软件开发团队：他们开发出真正有价值的应用程序、为用户的业务提供了实实在在的帮助，却因为没有遵循软件工程的最佳实践而懊恼不已。其实，他们大可不必这样想。在我看来，唯一能够检验团队能力的标准，就是看他们能否按时发布用户需要的软件、并在随后的时间里不断地补足、扩展这个软件。按时发布第一个版本固然重要，但始终及时地发布后续版本、并保证每个新版本都在原来的基础上有所提升，这可能是更加重要的。常常有人问我“如何雇佣好的开发者”。面对这个问题，我的回答总是：去找那些成功地开发过几个应用程序、并在交付后仍然留在项目组中直到下一个升级或维护版本发布的开发者。能够交付最初的产品，就说明这个人有能力开发出可用的产品；参与第二个版本的开发则使他有机会反思自己最初的开发方式带来的效果。如果某个开发者把这样的过程重复了三遍，我敢打赌他在软件开发工艺方面已经拥有了足够的技能和经验，这将使他能够继续获得成功。在本书的书名中，我把软件工艺称为“新的渴求”。之所以这样说，是因为我发现软件开发社群中的很多人开始盲目地追逐新技术，而忘记了真正重要的东西。软件开发的终极目标是要创建出高质量的、坚固的软件程序，并使之为用户创造价值。现在，我们的当务之急就是要培养出新一代的合格开发者，让他们拥有实现这一目标的能力。 “为用户创建应用程序”的过程曾经是妙趣横生、激动人心的，但软件工程几乎完全抹杀了这种令人愉悦的体验。现在，软件工艺将把软件开发过程中的乐趣和激动重新还给软件开发者。 Pete McBreen

用户评论

	zxssdd1985 说：我喜欢这本书。因为他给出了我们程序员存在的意义。程序员不是简单的体力劳动者，他们的劳动更像是在创做艺术。我已经不在关心他的内容是否正确，或者对与软件开发有多大的帮助。至少，它让我更爱程序员这个职业，让我觉得这是一个有意义的工作。发布于2008-10-19 22:28:20 (5)回应有8人认为此评论有用，有4人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	219.144.122.143 说： 123321 发布于2005-11-19 2:55:47 (0)回应有0人认为此评论有用，有0人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	221.200.30.120 说： w 发布于2005-8-2 13:56:26 (0)回应有0人认为此评论有用，有1人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	YuLimin 说：唯趣方超，唯专方精！发布于2005-1-12 14:41:28 (0)回应有1人认为此评论有用，有1人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	cuijinhong 说：没有做项目组长以前，不看这本书发布于2004-7-3 17:13:34 (0)回应有0人认为此评论有用，有2人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	210.21.227.66 说：很早以前就看过这本书，书中的很多观点着实说出了很多软件开发中的现实问题，但是当我前段时间看了本书作者的另外一本书《Questioning Extreme Programming》后，我对作者的思维彻底产生了怀疑，因为作者在这两本书中表达了两种非常相反观点，另外困惑。且看下面书评片断。 “... McBreen's whole discussion on incremental design is where my confusion began. McBreen wrote an entire book, Software Craftmanship, discussing how what most of us do today is not software engineering; it is instead craft. The premise of that book is that software is malleable, and we can easily shape or craft it from nothing into a robust product. In contrast, engineering is presented as a paradigm where we do significant planning up front because either we must or because it is too costly to change things later. (Many real engineers will refute this statement, though.) And thus we do not engineer software, we craft it with care, largely because we are able to. Personally I loved the book. Yet Questioning XP seems to refute the craft metaphor, as McBreen wishes for a process where we can do perfect design up front. He also wishes for developers not to be burdened by having to show constant love and care for their craft. Unfortunately, that's what craft is all about: craft will fail if its practitioners are not disciplined. If McBreen wants us to believe him in Questioning XP, then he should refute his earlier conclusions in Software Craftmanship. ... " 发布于2004-6-22 12:46:19 (0)回应有0人认为此评论有用，有0人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	210.82.111.71 说：看了我们国内做的软件，再和国外的比较一下，从软件的创意、美观、可操作性，用户感受度各个方面实在是无法相提并论，不是我崇洋媚外，实在是不堪入目，当然也包括我自己写的一些东西－－真是个“东西”，而不是作品。我们是时候学学国外的工艺学了，不仅在汽车一些产业，同样软件行业也需要，我们不能再在软件工艺方面输太多了。发布于2004-6-19 3:44:23 (1)回应有1人认为此评论有用，有1人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	openlinux 说：虽然你引经据典说了一大通,可我还是不同意的你观点。工匠就是工匠，大师就是大师。程序员们总会不自觉地表现出一种自恋倾向，总会的自己的工作是一种创造，一种艺术。在某种程度来说，或许正确，但在现代软件技术发展越来越迅速的时代，软件开发早已不是原来的那种个人英雄主义时代了。程序员也变成越来越工匠化，甚至机械化。软件蓝领的出现就是一个很好的注释。工匠和大师的区别是：工匠的影响是局部的、短暂的，而大师的影响是广阔的、深远的。具体到计算机行业来说，工匠只是影响某个公司的某个产品，比如：delphi，比如com，而大师影响的却是一个领域甚至整个计算机行业，比如：冯.诺伊曼的计算机体系机构至今还是计算机体系机构的基础。工匠的贡献，顶多不过是哲学上所说的“量变”，而大师的贡献，则由“量变达到了质变”。秦皇的兵马踊个个栩栩如生，神态各异，但终归大家只不过赞赏秦的工匠技艺高超。 gigix说了一大通，无非是想说明，工匠并不象很多人想象的那么差，那么“低贱”，这点我倒是同意gigix的观点。其实当工匠也挺不错的。人人都想当牛顿、爱因撕坦，可又有几人能有那种大师的天赋呢？我一直以为，想当大师是非得有点天赋才行的。所以，还是让上帝的归上帝凯撒的归凯撒吧。发布于2004-5-11 12:55:28 (5)回应有2人认为此评论有用，有5人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	218.70.163.103 说：有读过全书的没，出来说句话！发布于2004-5-8 9:54:26 (0)回应有0人认为此评论有用，有1人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
	218.70.163.103 说：看了前两章，感觉比较杂乱！发布于2004-5-8 9:53:50 (5)回应有3人认为此评论有用，有2人认为没用，您认为呢？
	正在读取本评论的讨论，请稍侯……
>>发表评论 >>查看更多评论

商品意见

>>我要提问

购买本书顾客还购买过

购买向导	如何付款	如何配送	订单信息	售后服务
购买流程	货到付款	送货方式、时间及费用	订单状态处理	退换货原则
搜索商品	邮局汇款		如何修改订单	退换货方法
	银行电汇		查询订单方法	相关问题说明
	网上支付
	其他支付方式


请输入图中的验证码