软件开发者路线图：从学徒到高手

.第3章 走过漫漫长路
漫漫长路
技重于艺
持续动力
培养激情
自定路线
使用头衔
坚守阵地
另辟蹊径
总结
第4章 准确的自我评估
只求最差
找人指导
同道中人
密切交往
打扫地面
总结
第5章 恒久学习
提高带宽
不断实践
质脆玩具
使用源码
且行且思
记录所学
分享所学
建立馈路
学会失败
总结
第6章 安排你的课程
阅读列表
坚持阅读
钻研名著
深入挖掘
常用工具
总结
第7章 结束语
附录a 模式列表
附录b 一次学徒培训的号召
附录c 回顾obtiva学徒训练项目的第一年
附录d 在线资源
参考文献

.　　我们（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 邮件列表中的长时间讨论，特起草如下宣言。
　　作为胸怀大志的“软件技师”，我们在亲身实践专业化软件开发，同时帮助他人掌握这一技艺，以此设立专业化软件开发的更高标准。基于这
　　些工作，我们认为：“可工作的软件”犹嫌不足，尚需精益求精的软件；
　　“响应变化”犹嫌不足，尚需稳步增加价值；
　　“个体与交互”犹嫌不足，尚需专家社区；
　　“客户协作”犹嫌不足，尚需卓有成效的伙伴关系。
　　也就是说，在追求左侧项目的过程中，我们发现右侧项目也是不可或缺的。
　　

.