本书讲述学徒模式，收录了数十种行为模式，来帮读者完善软件工艺技能的主要方面。这些模式凝结了多年的调查研究，无数次的访谈，以及来自O’Reilly在线论坛的反馈，可以解决程序员、管理员和设计者们每天都会面对的困难情形。本书讲的不只是经济方面的成功，还把软件开发看成一种自我实现的途径。

Software Engineering
Apprenticeship PatternsHoover & Oshineye
　　“了不起的作品！阅读本书就像置身于一部时间机器中，把我带回软件开发者职业生涯中的那些关键的学习时刻，那时，学习最佳的实践方法需要通过艰苦的方式，但是在我从学徒到高手的每一步上都有良师益友坐在旁边。我当然乐意把这本书介绍给大家。我多么希望14年前就拥有了这本书！”
　　——Russ Miles，OpenCredo CEO

　　作为一名软件开发者，你在奋力推进自己的职业生涯吗？面对今天日新月异和不断拓展的技术，取得成功需要的不仅仅是技术专长。为了增强专业性，你还需要一些软技能以及高效的学习技能。本书的全部内容都是关于如何修炼这些技能的。两位作者Dave Hoover和Adewale Oshineye给出了数十种行为模式，来帮你提高主要的技能。
　　本书中的模式凝结了多年的调查研究、无数次的访谈以及来自O’Reilly在线论坛的反馈，可以解决程序员、管理员和设计者每天都会面对的困难情形。本书介绍的不只是经济方面的成功，学徒模式还把软件开发看成一种自我实现的途径。读一读这本书吧，它会帮你充分利用好自己的生命和职业生涯。
　　厌倦了自己的工作？去找一个玩具项目来帮你重拾解决问题的乐趣吧，这叫“培养激情”。
　　感觉要被新知识淹没了？做点以前做过的事情，重新探索一下自己熟悉的领域，然后通过“以退为进”再次前进。
　　学习停滞了？那就去寻找一支由富有经验和才能的开发者组成的团队，暂时呆在里面“只求最差”。

　　Dave H. Hoover：Obtiva首席技师，喜欢在开发软件的同时培养软件开发者，他的专长是向企业家们交付项目。
　　Adewale Oshineye：软件工程师，从事过包括电子零售商销售网点系统、投资银行交易系统在内的各种大型项目开发。

不知而不知其不知者，愚者也——避之！
不知而知其不知者，惑者也——授之！
知之而不知其知之者，寐者也——醒之！
知之而知其知之者，觉者也——从之！
——Isabel Burton（1831—1896 ）女士在
《The Life of Captain Sir Richard F. Burton 》
（Richard F. Burton 上尉的一生）
一书中引用的阿拉伯谚语
本书目标
　　缺少经验的软件开发者常常面对进退两难的境地。为分享摆脱这类窘境的方法，我们写了这本书。我们指

的不是技术上的窘境；本书中你不会找到任何Java 设计模式或者Ruby on Rails 诀窍。相反，我们所致力于

解决的窘境是跟人有关的，是关于动机和士气的。作为专业软件开发领域的新人，你会面对一些艰难的决定，

本书将帮助你做出这些决定。
读者对象
　　本书写给那些对软件开发有过一些体验并立志成为软件开发高手的人。你可能是一名Web 应用开发者，或

者是一名医疗设备程序员，或者正在为一家金融机构开发交易应用。你也可能刚从中学或大学毕业，并认为软

件就是你的未来。
　　尽管本书是写给新人的，经验丰富的开发者仍可从本书内容中受益。有过几年开发经验的人，当从书中找

到自己曾经面临过的窘境时，会不住地点头，而且还可能获得新的感悟，或至少获得一个新的词汇，用于描述

他们自己使用或者建议给同行使用的方案。即使拥有十几年或者更长时间开发经验的人，特别是那些正在努力

把握职业航向的人，也将会找到一些灵感和视角，用来抵御晋升到管理职位的诱惑。
写作过程
　　本书的构思始于2005 年初，Stickyminds.com 请Dave 写关于软件工艺（Software Craftsmanship ）的

专栏。那时Dave 认为自己是个（有经验的）学徒（apprentice ），唯一让他写起来感觉舒服的主题就是学徒

期（apprenticeship ）。这使他开始考虑关于这个主题写些什么更好。大约就在那时，Dave 读到一篇由软件

开发者Chris Morris 发表的网志注1，其中提到了吉他手Pat Metheny ，而“只求最差”这一概念成了模式语

言的种子。这粒种子很快从Dave 的网志注2成长为Dave 用来组织最初一些模式的个人wiki 。最初的一些模式

就是从Dave 到那时（2000—2005） 的职业生涯中提取出来的。
　　Dave 知道，这些所谓的模式不能真正称为模式，除非它们确实是常见问题的一般解决办法。他开始通过

三种方式从同行那里寻求反馈。第一，他开始在自己的网站上公开发表这些模式，通过公众点评的方式寻求反

馈。第二，他开始访谈一些软件开发领域的思想领袖（主要通过电子邮件），并获得他们对最初几种模式的看

法。第三，也是最重要的一种，Dave 开始访谈一些经验较少的从业者，用他们新近的经验来检验这些模式。

这些经验较少的从业者们还把一些Dave 不曾遇到的或者在他的经验中不曾觉察到的模式介绍给他。就在这些

关于学徒期的访问中Dave 访问了Ade ，经过双方同意，Ade 加入到这个项目中并成为一名合著者。
注1： http://clabs.org/blogki/index.cgi page=/TheArts/BeTheWorst.
注2： Red Squirrel Reflections （ 红松鼠沉思录）， 参见：http://redsquirrel.com/cgibin/dave 。
　　我们（Dave 和Ade ）访谈了生活和工作在全世界很多地方的人们，从澳大利亚到印度再到瑞典。讨论的

形式也五花八门，从LiveJournal 网站的评论，到伦敦金融区中心一座美丽的被炸教堂遗址里进行的访问。
　　与此同时，其他一些人，如Laurent Bossavit 、Daragh Farrell 和Kraig Parkinson ，他们勇敢地在各

种练习班、研讨会和新手训练营中尝试使用这些模式。之后他们把收到的反馈传给了我们（Dave 和Ade ），

而我们则竭尽全力地把这些反馈合并到我们的笔记中。
　　在2005 年末的时候，我们在“程序的模式语言”（Pattern Languages of Programs，PLoP ）研讨会注3

上发起了一个主题小组。在PLoP 上，我们得以将自己的工作呈现给那些经验丰富的模式作者（也称为牧羊人

，shepherd ）们，他们在模式的组织形式方面给了我们许多反馈，并用自己的程序开发经验测试了我们的论

断。
　　大概在同一时间，来自O’Reilly Media 的Mary Treseler 联系了我们，提出了出版这些模式的建议，并

鼓励我们继续写作。她帮我们做了一些编辑工作，两年之后我们就书的出版达成协议。在那段时间里，通过电

子邮件、用户组和讨论会，甚至午餐时的谈话，我们同数不清的同行就这些模式进行交流，同时我们继续在

http://apprenticeship.oreilly.com 在线社区上寻求反馈。
　　最终的结果就是你手上的这本书。这是一部基于与从业者之间的无数次交流的作品，也是一部对已有的关

于学习、最佳效率心理学，以及所有我们能找到的与掌握知识相关的文献进行广泛研究的作品。随着阅读的
深入，你将看到，除了通常的软件领域的名人之外，我们还会引用外科医生、舞蹈编导还有哲学家的话。我们

相信，向任何一门学科的高手学习，我们都能收获很多。
　　注3： http://hillside.net/plop/2005/group1.html.
内容编排
　　模式是对特定上下文中某个问题的可重现解决方案的命名描述。这种描述应使读者对问题产生足够深入的

理解，使他们或者能将所述方案应用到自己的情景中，或者能确定某个方案对他们的情景不适合。
　　本书由较长的几章组成，每章都填满了一组彼此相关的模式。模式的名字以首字母大写（这是指英文原版

书——编辑注）拼出（如“质脆玩具”，Breakable Toys ），而相关的模式则频繁引用。每一章都把其中的

模式编排在一起，并提供一个对本章主题的介绍，以及一个进行总结的小节。本书的绪论部分为模式语言打下

基础，而结束语部分则审视了有关技巧、学徒期和掌握专业知识的“大图景”。
模式的形式
　　我们的模式形式与众不同。如果你读过其他关于模式的书籍，你会看到在本书中我们尝试了一些不同的东

西。同大多数模式语言相比，我们关于抽象外因和约束的章节不多，相关的讨论也较少。选择这种形式是基于

来自审稿人和PLoP 研讨会的广泛反馈。基于这些反馈，我们相信这种简单的结构将使我们的模式语言更易被

目标读者接受和理解。
　　我们的模式都包含一个“情景分析”、一个“问题描述”和一种“解决方法”，然后是一组单一或多重的

行动。“情景分析”设好基调，“问题描述”则确定模式所解决的问题。“解决方法”通常从问题的一句话分

析开始，接着深入到与运用方法有关的各类细节问题上，其间描述该模式与其他模式的关系，还有支持该模式

的故事和文献。
　　在每种模式接近尾声的地方都有一个“行动指南”的小节，这一小节描述了你可以立即付诸实践的具体事

情，如果你愿意体验模式效果的话。这些行动可用作实施的示例，它们提供了一些练习，你可以立即投入实
践，这样就不用担心模式是否可用于你身边的情形。
　　任何模式都应包含给定情景中一大类问题的一揽子解决方案，记住这一点很重要。模式是用来修正以适应

具体情形的，而不是用来生搬硬套的。因此，如果一种模式不能准确适用于你的情形，或者“行动指南”小节

中任何一条看起来都不合适，那么你应该尝试沿着我们提供的材料进一步外推，看看能否构造出一些有用的东

西。
　　大多数模式都以一个“参考模式”的小节结尾，这一小节指出了相关模式的页码。这样你阅读的时候就可

以不采用线性顺序，而是采用一种迂回的顺序，从而加深你对不同模式间关系的理解。
用法
　　模式语言将创造的力量赋予每一个使用它的人，使他们创造出无数独特的新构造，正如一般意义上的“语

言”给予他们创造无数句子的力量一样。
——《The Timeless Way of Building 》（建筑的永恒之道），第167 页
　　我们这个项目的目标是创建一种模式语言，来帮你定义自己的学徒过程。我们不可能知道你所处的实际环

境，因此一定要考虑每种模式的情景分析和问题描述来确定它是否适合你。这些模式之间是相互联系的，可以

联合使用来创造更强有力的体验。比如，尽管“找人指导”本身就是一种优秀的、经过时间检验的模式，但将

它跟“密切交往”结合起来会更强大。另一方面，“暴露无知”更加依赖一些支持模式，比如“正视无知”和

“以退为进”，而且需要多用一点技巧才能正确使用。跟所有的模式语言一样，你应该小心，不能过度使用这

些模式。不要为使用各种模式而寻找借口，而应针对具体情形遴选最恰当的组合。
　　你不一定要按从头到尾的顺序阅读书中的模式。当初Dave 阅读Christopher Alexander 的《A Pattern

Language 》（模式语言）时，就是从书的中间开始，并沿着模式之间的关联来阅读，这带来了一种更有趣的

学习体验。你也许只想简单浏览一下各种模式的情景分析和问题描述来找到跟你的实际情形最切合的模式。按

这种方式来扫描模式可以让你在大脑中安装一些触发器来应对未来情形，那时，你会突然发现某些模式可以应

用。
　　本书的内容最初写在一个wiki 上，它自然从未真正考虑过让人按线性顺序阅读。前面的模式会引用到后

面的模式，反之亦然。这会带来一些挑战，而且需要你积极地投入到这些内容中。你可以像浏览一个网站那样
浏览它，这会使你的注意力被各种有趣的链接分散，而永远不知道是否读完了所有的内容。但这种方法并没什

么不好。
　　我们当然理解一些人更喜欢从头到尾地阅读。因此，我们在前面的几章中做过一些努力，使前向引用减到

最少；前向引用是指一个模式会引用到书中在它之后出现的模式。
　　一些人会觉得他们需要把这本书通读两遍：首先，快速浏览，把所有的东西都记到脑子里；然后读二遍，

把所有的东西连接起来。这种方法也不错。本书并不适合用作参考手册，而更像一本艺术家的资料合集——你

可以时不时地翻阅它，从中汲取灵感。你甚至可能发明一些新的、我们从来没想过的使用本书的方法。尽管去

尝试。本书跟现实世界中其他的东西一样：彼此的关联不见得一下子就能看清，而每次回顾时，你都会发现新

的东西。
使用示例代码
　　本书的目的是帮你完成工作。一般来说，你可以将书中的代码用于你的程序或文档。除非你直接复制大段

代码，否则无需联系我们并获得许可。举例来说，在程序中使用几段书中的代码无需许可。出售或发布含有O

’Reilly 书中示例的CD-ROM 需经许可。引用本书中的叙述或示例代码来回答问题无需许可。将书中的大量代

码合并到你的产品文档中则需获得许可。
　　虽然我们并不要求在引用本书的时候做版权归属声明，但如果你这样做了，我们会非常感激。版权归属声

明通常包含标题、作者、出版者和ISBN 。例如：“Apprenticeship Patterns by David H. Hoover and
Adewale Oshineye 。Copyright 2010 David H. Hoover and Adewale Oshineye，978-0-596-51838-7. ”。
　　如果你觉得自己对书中示例代码的使用超出了正常范围，或者不符合以上描述的许可范围，请用电子邮件

跟我们联系：permissions@oreilly. com 。
我们的联系方式
　　你可以通过邮件地址dave.hoover@gmail.com 联系Dave ，或者访问他的主页，看看他最近又在做什么。
　　你可以通过邮件地址ade@oshineye.com 联系Ade 。通过他的网站可以连接到他的相册、作品和开放源代

码。
　　有关本书的建议和问题请与出版商联系：
　　美国：
　　O’Reilly Media, Inc.
　　1005 Gravenstein Highway North
　　Sebastopol, CA 95472
　　中国：
　　北京市西城区西直门南大街2号成铭大厦C座807 室（100035）
　　奥莱利技术咨询（北京）有限公司
　　本书也有相关的网页，我们在上面列出了勘误表、范例以及其他一些信息。你可以访问：
　　http://www.oreilly.com/catalog/9780596518387
　　（英文版）
　　http://www.oreilly.com.cn/book.php bn=978-7-111-31006-8
（中文版）
　　对本书做出评论或者询问技术问题，请发送E-mail 至：bookquestions@oreilly.com
希望获得关于本书、会议、资源中心和O’Reilly 网络的更多信息，请访问：
http://www.oreilly.com
http://www.oreilly.com.cn
Dave 的致谢
　　我要从感谢那些给我第一次机会让我成为软件工程师的人开始。Irv Shapiro，Edventions 公司的CEO，

2000 年4月在我们面谈结束时，他雇佣了我。那一年晚些时候，他把我介绍给了Steve Bunes（Edventions 公

司的CTO ）和Risetime Technologies 公司的CEO ，他们两位都在我开始兴奋地步入Perl 和程序设计的过程

中指导了我。2001 年4月，当Edventions 跟许多其他的“dot-com ”创业公司一样死去时，Steve 在美国医

学会（American Medical Association，AMA ）为我说了好多美言，在那里我度过了接下来的三年，从互联网

炸弹（dot-bomb ）的灾难中挺了过来译注1。我要重复一下在Irv 雇佣我的那个晚上，我向他敬酒时说过的话

：“感谢你，Irv ，感谢你愿意在我这个异教徒身上冒险一试。”
　　在美国医学会有两个人给了我第一次超越入门语言的机会。John Dynkowski 从我身上发现了一些潜力，

让我去做医学会最初的几个J2EE 项目。他为这事费了不少的政治成本，我在他的部门工作的18 个月里，他不

断地鼓励我。Doug Fedorchak ，我的直属上司，给我充分的自主权，让我向上层管理者推销极限编程Extreme

Programming ）方法，并让我启动了医学会里的第一个极限编程项目。感谢你们，John 和Doug ，是你们允许

像我这样经验不足却又热情洋溢的程序员来尝试自己的思想，并在你们的组织里“兴风作浪”。
　　如果要我说出一个对我和我的职业旅程产生了最大影响的人，那他就是
译注1： 当年dot-com 泡沫破裂被人戏称为dot-bombs 。注意在英语中，com 和bomb 的发音仅仅开口时的辅

音不同，一个是b，一个是c，再考虑到“bomb ”是炸弹的意思，就会觉得这是很有意思的双关语。
Wyatt Sutherland 。2002 年我在芝加哥敏捷开发者团体（Chicago Agile Developers group，ChAD ）中遇

见Wyatt ，那时他是团体的负责人。我向Wyatt 提议让我做他的“学徒”，他同意定期跟我会面，共进早餐和
午餐。他是一名四处奔波的敏捷开发顾问、一所本地大学的乐队指挥，还是四个孩子的父亲。尽管如此，他还

是做到了与我的定期会面。谢谢你，Wyatt ，谢谢你那些年对我的指导。这是一份无价的礼物，让我有信心离

开美国医学会，并立志到Object Mentor 或ThoughtWorks 这样的公司去工作。
　　我还要感谢我的前雇主ThoughtWorks ，是她让我接触了一大群有兴趣为本书献计献策的人，尤其是我的

合著者Adewale Oshineye 。感谢你，ThoughtWorks 的首席科学家Martin Fowler 译注2，感谢你抽时间和我

在一起分享你关于写作的见解。2005 年，Obie Fernandez 邀请我参加亚特兰大敏捷开发会议并作关于学徒模

式的报告，ThoughtWorks 慷慨地为我支付了路费。感谢你，Obie ，感谢你在奥本冈时在我们共同的项目中给

予我的支持与鼓励，感谢你邀请我参加亚特兰大敏捷开发会议，感谢你在我错过了回家的航班时让我睡在你的

住所。感谢你，我的朋友Laurent Bossavit ，你在2005 年法国极限编程会议上介绍了我们的模式，并帮我把

会议抄本翻译成英语。感谢你，Daragh Farrell ，感谢你在2005 年悉尼Geeknight 会议上介绍了我们的模式

，并将讨论的视频发给了我。感谢你，Linda Rising ，感谢你邀请我和Ade 参加了2005 年的“程序的模式语

言”研讨会，在那里我们收到了大量重要的反馈，而且第一次（迄今为止也是唯一一次）有机会见了面（再一

次感谢ThoughtWorks 让Ade 从伦敦飞到芝加哥来参加这次研讨会）。
　　在我刚开始研究这些模式时，我接触了很多软件开发社区的知名人士。他们付出宝贵的时间通过电话或电

子邮件与我交流，基于他们数十年的经验提供反馈和建议。我非常感激Ken Auer 、Jerry Weinberg 、Norm
Kerth 、Ron Jeffries 、Linda Rising 、Dave Astels ，还有Pete McBreen，
　　译注2： Martin Fowler ，企业级软件领域的著名作者、演讲人和咨询师，著有《Refactoring 》、

《UML Distilled 》及《Analysis Patterns 》等软件领域的名著，几乎每本都是畅销书。
　　感谢他们付出宝贵的时间在我写作过程中给予指导。同时，我（还有后来的Ade ）也接触了数十名经验并

不那么丰富的人（就像我一样），从他们那里寻求一些关于模式的输入，并从他们的故事中挖掘具有普适价值

的主题。
　　非常感谢以下人士：Adam Williams 、Chris McMahon 、Daragh Farrell 、Desi McAdam 、Elizabeth

Keogh 、Emerson Clarke 、Jake Scruggs 、Kragen Sitaker 、Ivan Moore 、Joe Walnes 、Jonathan

Weiss 、Kent Schnaith 、Marten Gustafson 、Matt Savage 、Micah Martin 、Michael Hale 、Michelle

Pace 、Patrick Kua 、Patrick Morrison 、Ravi Mohan 、Steven Baker 、Steve Tooke 、Tim Bacon 、

Paul Pagel 、Enrique Comba Riepenhausen 、Nuno Marques 、Steve Smith 、Daniel Sebban 、Brian

Brazil 、Matthew Russell 、Russ Miles ，还有Raph Cohn ，感谢他们与我通信，并把他们的思想和故事讲

给我们，供我们使用。
　　2008 年，我们启动了http://apprenticeship.oreilly.com ，在上面公布了这些模式内容，以期获得来

自社会的反馈。感谢所有为此作出贡献的人们，包括Julie Baumler 、Bob Beany 、Antony Marcano 、Ken

McNamara 、Tom Novotny 、Vikki Read 、Michael Rolf 、Joseph Taylor ，特别要感谢Michael Hunger ，

他是论坛上的活跃分子，在多次手稿复审中为我们提供了极好的反馈。
　　我还要对联合太平洋捷运西线（Metra Union Pacific West Line ）列车上每天的乘客们表示感激，这条

线路从芝加哥洛普区（Chicago ’s Loop ）开到西部郊区。本书的绝大部分内容都是在这列像图书馆一样安

静的列车上写就的。感谢你们，在我撰写本书时，你们都静静地读着你们的书。明天见！
　　2006 年，我加入了Obtiva 公司，当时Kevin Taylor 说服了我，他说我应该成为公司的第四名雇员，而

不是转包商。这绝对是个好建议，而且我从许多方面得到了回报。我要感谢Kevin ，感谢他支持我未经验证的

想法，将公司的一部分交由我支配，并且收拾那些不断被我制造出来的麻烦，照应公司业务中那么多乏味透顶

却又至关重要的方面。我为公司的未来感到振奋。Kevin 允许我实施的未经验证的想法之一就是建立Obtiva

公司的软件工作室，来带领那些我们可以培养成高级开发者的软件学徒。自从2007 年4月启动这个工作室，我

们带出了六名学徒，我必须向前三名软件学徒（Brian Tatnall 、Joseph Leddy 和Nate Jackson） 致以诚挚

的谢意，他们忍受了我太多的缺点和缺乏经验的表现。这些小伙子们所经历的试验和错误使我们逐渐改善了最

近三名学徒（Colin Harris 、Leah Welty-Rieger 和Turner King ）的训练过程。感谢所有六位学徒，感谢

你们的奉献、热情，以及常常在一个并不理想的环境中学习成长的意愿。
　　Mary Treseler 就是那个鼓励我们发布这一项目的人。自从2005 年她第一次读到我们最初的几个模式，

就在心中产生了共鸣，虽然她自己并不是一名程序员。感谢你，Mary ，虽然我们并没有写作的经验，你仍然

愿意倾听我们的意图，而且这些年一直坚持耐心地同我们交流。
　　我很幸运，成长在一个非常和睦的家庭中。尽管我们搬了好几次家，但我的爸爸妈妈作为孩子的父母、彼

此的爱人和基督信徒，处处给我们树立榜样。有了他们的行为榜样，我从成人、结婚到为人父母的过程都很顺

利。从很早的时候，Marcia Hoover 和Rick Hoover 就成了鼓励我写作的持续动力。感谢你们，妈妈，爸爸，

感谢你们开发了我喜欢写作的天性。
　　尽管我直到26 岁才开始编程，但我并没有浪费组建家庭的时间，女儿出生时我24 岁，在我研究生毕业的

几个月前。尽管在那种情况下组建家庭颇具挑战性，但我的孩子们带给他们父亲的一样东西就是让我有了对自

身责任的高度关注。自从1999 年Rose 出生以后，我不敢一天不工作，对一个正开启一条新的职业道路的人来

说，这是极大的动力。随着孩子们从婴儿长大成学龄的孩子，我从观察他们克服学习过程中的障碍当中得到了

启示。这提醒了我，让我谨记活到老学到老，像他们那样顽强地探求知识。Rose 、Ricky ，还有Charlie ，

感谢你们无条件地爱着老爸，并能忍受你们的第四个“兄弟”：老爸的笔记本电脑。现在这本书已经写完了，

你们以后见到它的时间应该会少一些了。我的妻子，Staci ，嫁给了大学足球队的队长。11 年之后，嫁给了

一个带着黑色厚框眼镜的小伙子，这个家伙喜欢学习编程语言，并在闲暇时间发起新的编程用户组。这两个人

都是我，Staci 就这样跟着我一路走来，看着我同自己骨子里的那个奇客（geek ）打交道。她忍受了我为所

欲为地钻入了无休止的书籍、博客、开源项目、写作项目和雇主老板当中。没有人比Staci 更了解我，也没有

人比她更能拴住我的心。谢谢你，Staci Sampson Hoover ，谢谢你使我能关注那些真正重要的事情。我会永

远爱你。
　　最后，我要感谢上帝，感谢您无条件地爱着我，并在我很多次将要失落的时候把我救起。我希望我写的这

本书能在某种意义上为您赞美。
Ade 的致谢
　　首先我要感谢Dave 感谢过的所有的人。没有他们，Dave 就不会在现在的地方，我也不会。
　　我要感谢《The Pragmatic Programmers 》（程序员修炼之道——从小工到专家）（Andy 和Dave 写的）

，是这本书给了我灵感，并把我带到了C2 wiki 和极限编程周二俱乐部。如果没有这些事情对我的影响，我就

不会找到Laurent Bossavit 的Bookshelved wiki ，也不会在Dave 加入ThoughtWorks 时知道他是谁。
　　当然，如果不是因为在一次老英国央行的XTC 晚会上，Paul Hammant 非要我对不想加入ThoughtWorks 这

件事给出合理的解释，我也不会成为那里的一名咨询师。谢谢你，Paul 。在ThoughtWorks 工作的经历为我打

开了很多扇门。比如，有了ThoughtWorks 前任创新总监（Innovation Director）Dave Farley 的赞助，我能

到Allerton 参加PLoP 会议，并见到Dave 。
　　那些花时间为本书接受职业详细资料问卷调查的人们，你们肯定知道我说的是谁。我无法把你们的名字全

部列在这里，但我永远感谢你们。对于本书的审稿者也是一样。感谢你们付出的宝贵时间，告诉我们怎样才
能使这本书更好。
　　Ravi Mohan 不只跟我们分享了他的经验。针对本书以及软件技能的各个方面，他都向我们提出了一些很

难的问题。他自愿地去做背景阅读，去改变自己的想法，并不断地询问问题的明确解释，这一切都让我们保
持诚实。感谢你，Ravi 。
　　我还要感谢Robert Konigsberg 和Eve Andersson ，感谢他们为本书手稿的早期版本提供了无比详尽的反

馈。
　　我要感谢Enrique Comba Riepenhausen ，感谢他们完成了最初的OmniGraffle 图表（OmniGraffle 是由

Omni Group 开发的基于Mac OS X 系统的可视化制图工具）。若没有他们的帮助，你看到的将是一些相当丑陋

的用Graphviz 自动产生的图表（Graphviz 是一套开源的可视化图形软件，来自AT&T 研究中心）。
　　如果没有人指导，写一本关于学徒方面的书将是不可能的任务。Ivan Moore 一直是我的指导者，虽然我

们现在已不再在一起工作。Ivan 的指导让我一直觉得快乐，就像我对茶的感觉一样。
　　我还要感谢Mary Treseler ，虽然我们延误了多个“最终期限”，你依然给我和Dave 完成这本书的机会

。
　　最后，我要感谢我的父母。他们给我买了第一台电脑，而且他们在很多年之前就意识到我应该成为一名专

业的程序员。如果我能在更小的时候就听他们的话，我的路将会更通畅更直接一些。
软件工艺宣言
注解
　　2009 年3月，经过software_craftsmanship 邮件列表中的长时间讨论，特起草如下宣言。
　　作为胸怀大志的“软件技师”，我们在亲身实践专业化软件开发，同时帮助他人掌握这一技艺，以此设立

专业化软件开发的更高标准。基于这些工作，我们认为：
　　“可工作的软件”犹嫌不足，尚需精益求精的软件；
　　“响应变化”犹嫌不足，尚需稳步增加价值；
　　“个体与交互”犹嫌不足，尚需专家社区；
　　“客户协作”犹嫌不足，尚需卓有成效的伙伴关系。
　　也就是说，在追求左侧项目的过程中，我们发现右侧项目也是不可或缺的。

“了不起的作品！阅读本书就像置身于一部时间机器中，把我带回软件开发者职业生涯中的那些关键的学习时刻，那时，学习最佳的实践方法不需要通过艰苦的方式，在我从学徒到高手的每一步上，都有良师益友坐在旁边。我当然乐意把这本书介绍给大家。我多么希望14年前就拥有了这本书！”
——Russ Miles，OpenCredo CEO
作为一名软件开发者，你在奋力推进自己的职业生涯吗？面对今天日新月异和不断拓展的技术，取得成功需要的不仅仅是技术专长。为了增强专业性，你还需要一些软技能以及高效的学习技能。本书的全部内容都是关于如何修炼这些技能的。两位作者Dave Hoover和Adewale Oshineye给出了数十种行为模式，来帮你提高主要的技能。
本书中的模式凝结了多年的调查研究、无数次的访谈以及来自O’Reilly在线论坛的反馈，可以解决程序员、管理员和设计者每天都会面对的困难情形。本书介绍的不只是经济方面的成功，学徒模式还把软件开发看成一种自我实现的途径。读一读这本书吧，它会帮你充分利用好自己的生命和职业生涯。
 厌倦了自己的工作？去找一个玩具项目来帮你重拾解决问题的乐趣吧，这叫“培养激情”。
 感觉要被新知识淹没了？做点以前做过的事情，重新探索一下自己熟悉的领域，然后通过“以退为进”再次前进。
 学习停滞了？那就去寻找一支由富有经验和才能的开发者组成的团队，暂时呆在里面“只求最差”。

（美）Dave H. Hoover；Adewale Oshineye　著：Dave H. Hoover：Obtiva首席技师，喜欢在开发软件的同时培养软件开发者，他的专长是向企业家们交付项目。 Adewale Oshineye：软件工程师，从事过包括电子零售商销售网点系统、投资银行交易系统在内的各种大型项目开发。

王江平 译：暂无简介

序 1
前言 5
软件工艺宣言 19
第1章 绪论 21
什么是软件技能 25
学徒期是什么 31
学徒模式是什么 32
模式来自哪里 33
下一步做什么 33
第2章 空杯心态 35
入门语言 38
白色腰带 45
释放激情 49
具体技能 51
暴露无知 54
正视无知 57
深水区域 59
以退为进 62
总结 64
第3章 走过漫漫长路 67
漫漫长路 69
技重于艺 71
持续动力 74
培养激情 77
自定路线 80
使用头衔 84
坚守阵地 85
另辟蹊径 87
总结 89
第4章 准确的自我评估 93
只求最差 94
找人指导 98
同道中人 101
密切交往 104
打扫地面 107
总结 109
第5章 恒久学习 113
提高带宽 114
不断实践 118
质脆玩具 121
使用源码 124
且行且思 128
记录所学 131
分享所学 133
建立馈路 136
学会失败 139
总结 140
第6章 安排你的课程 143
阅读列表 144
坚持阅读 147
钻研名著 148
深入挖掘 150
常用工具 155
总结 158
第7章 结束语 161
附录A 模式列表 167
附录B 一次学徒培训的号召 171
附录C 回顾Obtiva学徒训练项目的第一年 175
附录D 在线资源 179
参考文献 181