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

《软件开发者路线图：从学徒到高手ch01-02》由会员分享，可在线阅读，更多相关《软件开发者路线图：从学徒到高手ch01-02（66页珍藏版）》请在金锄头文库上搜索。

1、 序 25年前，我和Kent Beck坐在Tektronix技术中心的自助餐厅里，考虑着 我们对Smalltalk-80的深入接触会给世界带来怎样的影响。 我对Kent说：真的不必担心。如果我们能做任何事情，我们会做什么 呢？ “我想改变人们看待程序设计的方式。”Kent说。我表示赞同。那时， 我们都认为行业发展进入了错误的方向，而我们都想逆转它。而且，令 人惊奇的是，我们做到了。 我那时在自助餐厅中使用的这项技巧“真的不必担心”这部分 是最早从我大学的指导老师那里学到的一种模式。他把该模式用在我身 上，正如我把它用在Kent身上。这种行为我现在把它归结为一种模式， 它使我和Kent敢于想象更

2、远的目标，若非如此，那些目标看起来显得盲 目。而一旦想到了，我们的目标就更容易实现了。 我把这种思考的技巧称为模式，因为它解决了我们经常遇到的一个问 题：我们潜意识里会压抑自己的雄心壮志。本书中全是类似这样的技 巧，它们用于解决各种不同的问题。我们说：模式解决问题。“真的不 必担心”帮我和Kent解决了一个问题。它使我们真正去考虑自己本来就 有的更大的想法，而且使我们克服了习惯性的自我压抑。 或许你也尝试过“真的不必担心”这一模式。如果没有，不妨试一试。 序 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 最强大的模式是那些可以反复运用并取得成功的模式。模式并不一定非 要新颖才有用

3、。事实上，不新的模式才更好。另外，仅仅知道几个成型 的模式名字也没有太大帮助。确定出一种模式，以后你每次谈论它的时 候就不必重述整个故事。 快速翻阅这本书，你将看到很多模式，其中许多都会让你觉得熟悉。对任 何一个，你可能都会说“我已知道这种模式了”可能事实真的如此。 然而，即使相关解决方案是常识性的，书中的模式仍然能提供两种帮助你 的方法。 第一，书中的模式更加完整。它们已经被研究、定性、归类并解释过。 每一种模式都会带给你意外的收获。尽情享受这种收获吧，它会帮助你 让已知的模式变得更加强大。 第二，这里的模式都是相互关联的。每一种模式都通向其他的多种模 式。当你发现一种已经知晓的模式，沿着这

4、些关联，你可以顺藤摸瓜找 到其他一些尚未知晓或者从没想过可与之联合运用的模式。 我和Kent在Smalltalk-80中挖掘模式，我们找到了很多。我们将这些模 式的概念讲给了同事们，并引发了一场小小的革命。我们改变了人们考 虑程序设计的方式。从那时开始，人们写出了几十本有关模式以及如何 使用它们的书籍。 我们的革命远未结束。慢慢地，模式术语越来越多，并成为敏捷 （Agile）软件开发方法的基础。后来又出现了几十本书籍。 那现在为什么写这本书呢？好吧，我们的职业已经承载了过多的资源。 关于我们的革命，有太多的信息可以获取，以至于没有人能完全吸收它 们。然而，还是有些人努力做到了。他们消化了所有可

5、以获得的建议， 而且似乎总能在需要时信手拈来。他们是如何掌握到这种程度的呢？ 本书的内容全都是教你如何掌握我们所处的复杂领域的模式。掌握不只 是知晓。掌握是能帮你减轻负担的知晓。 序 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 举个例子，如果你记不住SUBSTR函数的参数顺序，可以到互联网上查 一查。感谢上帝赐予我们互联网，它把我们的负担减轻了一点点。但 是，当你运用本书中的模式，当你可以随时改善自己的工作，你会发 现自己在写一种不同的代码，一种不依赖于了解SUBSTR参数顺序的代 码。你将写出比SUBSTR飞得更高的程序，而这将大大减轻你的负担。 来自这次革命中的所有建议，除

6、非能成为你的第二天性，否则就不会有 太大的帮助。在软件领域，工艺的发展使我们认识到，让这些东西变成 第二天性并不是我们的第二天性。这些模式是对这一过程的贡献，令人 欢迎的贡献。 Ward Cunningham 前言 不知而不知其不知者，愚者也避之！ 不知而知其不知者，惑者也授之！ 知之而不知其知之者，寐者也醒之！ 知之而知其知之者，觉者也从之！ Isabel Burton（18311896）女士在 The Life of Captain Sir Richard F. Burton （Richard F. Burton上尉的一生） 一书中引用的阿拉伯谚语 本书目标 缺少经验的软件开发者常常面对进

7、退两难的境地。为分享摆脱这类窘境 的方法，我们写了这本书。我们指的不是技术上的窘境；本书中你不会 找到任何Java设计模式或者Ruby on Rails诀窍。相反，我们所致力于解 决的窘境是跟人有关的，是关于动机和士气的。作为专业软件开发领域 的新人，你会面对一些艰难的决定，本书将帮助你做出这些决定。 读者对象 本书写给那些对软件开发有过一些体验并立志成为软件开发高手的人。 你可能是一名Web应用开发者，或者是一名医疗设备程序员，或者正在 为一家金融机构开发交易应用。你也可能刚从中学或大学毕业，并认为 软件就是你的未来。 前言 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 尽管本

8、书是写给新人的，经验丰富的开发者仍可从本书内容中受益。有 过几年开发经验的人，当从书中找到自己曾经面临过的窘境时，会不住 地点头，而且还可能获得新的感悟，或至少获得一个新的词汇，用于描 述他们自己使用或者建议给同行使用的方案。即使拥有十几年或者更长 时间开发经验的人，特别是那些正在努力把握职业航向的人，也将会找 到一些灵感和视角，用来抵御晋升到管理职位的诱惑。 写作过程 本书的构思始于2005年初，S 请Dave写关于软件工艺 （Software Craftsmanship）的专栏。那时Dave认为自己是个（有经验 的）学徒（apprentice），唯一让他写起来感觉舒服的主题就是学徒期 （a

9、pprenticeship）。这使他开始考虑关于这个主题写些什么更好。大约 就在那时，Dave读到一篇由软件开发者Chris Morris发表的网志 注1 ，其 中提到了吉他手Pat Metheny，而“只求最差”这一概念成了模式语言 的种子。这粒种子很快从Dave的网志 注2 成长为Dave用来组织最初一些 模式的个人wiki。最初的一些模式就是从Dave到那时（20002005） 的职业生涯中提取出来的。 Dave知道，这些所谓的模式不能真正称为模式，除非它们确实是常见 问题的一般解决办法。他开始通过三种方式从同行那里寻求反馈。第 一，他开始在自己的网站上公开发表这些模式，通过公众点评的方

10、式寻 求反馈。第二，他开始访谈一些软件开发领域的思想领袖（主要通过电 子邮件），并获得他们对最初几种模式的看法。第三，也是最重要的一 种，Dave开始访谈一些经验较少的从业者，用他们新近的经验来检验 这些模式。这些经验较少的从业者们还把一些Dave不曾遇到的或者在 他的经验中不曾觉察到的模式介绍给他。就在这些关于学徒期的访问中 Dave访问了Ade，经过双方同意，Ade加入到这个项目中并成为一名合 著者。 注1： http:/clabs.org/blogki/index.cgi?page=/TheArts/BeTheWorst. 注2： Red Squirrel Reflections（红松鼠

11、沉思录），参见： bin/dave。 前言 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 我们（Dave和Ade）访谈了生活和工作在全世界很多地方的人们，从澳 大利亚到印度再到瑞典。讨论的形式也五花八门，从LiveJournal网站的 评论，到伦敦金融区中心一座美丽的被炸教堂遗址里进行的访问。 与此同时，其他一些人，如Laurent Bossavit、Daragh Farrell和Kraig Parkinson，他们勇敢地在各种练习班、研讨会和新手训练营中尝试使 用这些模式。之后他们把收到的反馈传给了我们（Dave和Ade），而我 们则竭尽全力地把这些反馈合并到我们的笔记中。 在

12、2005年末的时候，我们在“程序的模式语言”（Pattern Languages of Programs，PLoP）研讨会 注3 上发起了一个主题小组。在PLoP上，我 们得以将自己的工作呈现给那些经验丰富的模式作者（也称为牧羊人， shepherd）们，他们在模式的组织形式方面给了我们许多反馈，并用自 己的程序开发经验测试了我们的论断。 大概在同一时间，来自OReilly Media的Mary Treseler联系了我们，提 出了出版这些模式的建议，并鼓励我们继续写作。她帮我们做了一些编 辑工作，两年之后我们就书的出版达成协议。在那段时间里，通过电子 邮件、用户组和讨论会，甚至午餐时的谈话，

13、我们同数不清的同行就这 些模式进行交流，同时我们继续在 在线 社区上寻求反馈。 最终的结果就是你手上的这本书。这是一部基于与从业者之间的无数次 交流的作品，也是一部对已有的关于学习、最佳效率心理学，以及所有 我们能找到的与掌握知识相关的文献进行广泛研究的作品。随着阅读的 深入，你将看到，除了通常的软件领域的名人之外，我们还会引用外科 医生、舞蹈编导还有哲学家的话。我们相信，向任何一门学科的高手学 习，我们都能收获很多。 注3： 前言 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 内容编排 模式是对特定上下文中某个问题的可重现解决方案的命名描述。这种描 述应使读者对问题产生足够深入

14、的理解，使他们或者能将所述方案应用 到自己的情景中，或者能确定某个方案对他们的情景不适合。 本书由较长的几章组成，每章都填满了一组彼此相关的模式。模式的 名字以首字母大写（这是指英文原版书编辑注）拼出（如“质脆玩 具”，Breakable Toys），而相关的模式则频繁引用。每一章都把其中 的模式编排在一起，并提供一个对本章主题的介绍，以及一个进行总结 的小节。本书的绪论部分为模式语言打下基础，而结束语部分则审视了 有关技巧、学徒期和掌握专业知识的“大图景”。 模式的形式 我们的模式形式与众不同。如果你读过其他关于模式的书籍，你会看到 在本书中我们尝试了一些不同的东西。同大多数模式语言相比，我

15、们关 于抽象外因和约束的章节不多，相关的讨论也较少。选择这种形式是基 于来自审稿人和PLoP研讨会的广泛反馈。基于这些反馈，我们相信这 种简单的结构将使我们的模式语言更易被目标读者接受和理解。 我们的模式都包含一个“情景分析”、一个“问题描述”和一种“解决 方法”，然后是一组单一或多重的行动。“情景分析”设好基调，“问 题描述”则确定模式所解决的问题。“解决方法”通常从问题的一句话 分析开始，接着深入到与运用方法有关的各类细节问题上，其间描述该 模式与其他模式的关系，还有支持该模式的故事和文献。 在每种模式接近尾声的地方都有一个“行动指南”的小节，这一小节描 述了你可以立即付诸实践的具体事情，

16、如果你愿意体验模式效果的话。 这些行动可用作实施的示例，它们提供了一些练习，你可以立即投入实 践，这样就不用担心模式是否可用于你身边的情形。 任何模式都应包含给定情景中一大类问题的一揽子解决方案，记住这一 点很重要。模式是用来修正以适应具体情形的，而不是用来生搬硬套 前言 软 件 开 发 者 路 线 图 ： 从 学 徒 到 高 手 的。因此，如果一种模式不能准确适用于你的情形，或者“行动指南” 小节中任何一条看起来都不合适，那么你应该尝试沿着我们提供的材料 进一步外推，看看能否构造出一些有用的东西。 大多数模式都以一个“参考模式”的小节结尾，这一小节指出了相关模 式的页码。这样你阅读的时候就可以不采用线性顺序，而是采用一种迂 回的顺序，从而加深你对不同模式间关系的理解。 用法 模式语言将创造的力量赋予每一个使用它的人，使他们创造出无 数独特的新构造，正如一般意义上的“语言”给予他们创造无数 句子的力量一样。 The Timeless Way of Building（建筑的永恒之道），第16