在过ȝ十年中，CEO 们在产生Ex(chng)增加的收入方面面临巨大的压力。他们通过在许多方面采取一pd举措来解册一问题Q例如羃?yu)公司规模、外包、再工程、企业资源规?(ERP) {等。这些对低效率的解决措施?S&P 500 中的许多企业?90 q代末能够连l几q保持两位数的收入增ѝ但q种方式也带来了(jin)一些负面媄(jing)响?/p>
?Gary Hamel 所著的 Leading the RevolutionQ请参阅 参考资?/font>Q一书中Q他声称已有一些迹象证明传l企业模式的优势已不那么明显。我们必LC些替代方法来为收入的持箋(hu)增长提供动力。他唯一能让公司l箋(hu)增长的办法是q行一ơ彻底的创新。我们认为在软g开发领域中其需要这栗?
如果使用标准软g开发方法，那么即?Java q_上进行开发，也要做好失望的准备。如?1 所C，最q的研究表明Q有一半项目将滞后Q而三分之一的项目将过预算。这一推测?1979 q由国d计局的研I结果好不了(jin)多少?/p>
?1. 软g目成功和失败，q去和现?
如果我们希望q些数字有显著提高，则需要彻底创新的Ҏ(gu)来开发Y件。有两个主要因素影响现有的方法：(x)
- 惧怕失?
- 对Y件本质的误解
没有人打失败。具有讽刺意味的是ؓ(f)使失败最化而创建的Ҏ(gu)是失败的。对软g的误解是问题的根源。恐惧实际上只是一U症状。现有的Ҏ(gu)是由那些有良好愿望但忘记?jin)Y件中?#8220;?#8221;的那些聪明h所创徏的。他们假定开发Y件就象造桥。因此他们从各种设计规范中借鉴?jin)一些适用?#8220;?#8221;物体Q例如桥梁）(j)的最优方法。结果是Z Big Design Up-front (BDUF) 思想的反映迟钝的开发方法，软g不堪一击，Z无法使用它们?/p>
  |
|
最q发生了(jin)一些{变，从所谓的“重量?#8221;Ҏ(gu)转向?#8220;轻量?#8221;?#8220;灉|”Ҏ(gu)Q例?Crystal Ҏ(gu)、适应性Y件开发和Q当前最行的）(j)XP。所有这些过E都有这样一个事实，即需要h们共同来开发Y件。成功的软gq程必须h们的长处最大化Q将他们的缺Ҏ(gu)化Q因Z点和~点毋庸质疑都存在。在我们看来QXP 最?gu)的地方在于它能够解决所有媄(jing)响参加h员的互补力量?/p>
XP 提供?jin)十q来最大的一ơ机?x)，lY件开发过E带来彻底变革。就?Peopleware 作家 Tom DeMarco 所_(d)“XP 是当今我们所处领域中最重要的一运动。预计它对于目前一代的重要性就?SEI ?qing)其能力成熟度模型对上一代的重要性一栗?#8221;
XP 规定?jin)一l核?j)h(hun)值和Ҏ(gu)Q可以让软g开发h员发挥他们的专长Q编写代码。XP 消除?jin)大多数重量型过E的不必要物，通过减慢开发速度、耗费开发h员的_֊Q例如干特图、状态报告，以及(qing)多卷需求文档）(j)从目标偏R我们认识到一个称?#8220;极端~程”的东西可能很难作为正式的开发过E推荐给理层，但如果?zhn)的公总事Y件行业，(zhn)应该帮助管理层l过其名U认识到 XP 可以提供的竞争优ѝ?/p>
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change一书中概括?XP 的核?j)h(hun)|请参?参考资?/font>Q。我们对它们q行?jin)ȝQ?
- 交流?/strong> 目的问题往往可以q溯到某人在某个时刻没有和其他h一起商量某些重要问题(sh)。?XPQ不交流是不可能的事?
- 单?/strong> XP (zhn)L可能围l过E和~写代码做最单的事情。按?Beck 的说法，“XP 是打赌。它打赌今天最好做些简单的?..而不是做更复杂但可能永远也不?x)用到的事?#8221;
- 反馈?/strong> 更早和经常来自客戗团队和实际最l用L(fng)具体反馈意见为?zhn)提供更多的机会(x)来调整?zhn)的力量。反馈可以让(zhn)把握住正确的方向，走弯\?
- 勇气?/strong> 勇气存在于其它三个h(hun)值的环境中。它们相互支持。需要勇气来怿一路上具体反馈比预先知道每样事物来得更好。需要勇气来在可能暴露?zhn)的无知时与团队中其他Z。需要勇气来使系l尽可能单，明天的军_推到明天做。而如果没有简单的pȝ、没有不断的交流来扩展知识、没有掌握方向所依赖的反馈，勇气也就失去?jin)依靠?
- 单?/strong> XP (zhn)L可能围l过E和~写代码做最单的事情。按?Beck 的说法，“XP 是打赌。它打赌今天最好做些简单的?..而不是做更复杂但可能永远也不?x)用到的事?#8221;
XP 的方法将q些价D{换成开发h员每天应做的事情。这里没什么新鲜内宏V多q以来，行业认识?XP Ҏ(gu)?#8220;最优方?#8221;。实际上QXP 中的“极端”来自两方面：(x)
- XP 采取l过证明的业界最优方法ƈ其发挥到极致?
- XP 这些方法以某种方式q行l合Q它们产生的结果大于各部分的d?
q是怎样的情景呢Q代码复查是个好的做法，因此始终通过成对地编写代码来做到。测试也是个好的做法Q因此L通过在编写代码之前编写测试来做到。文档很与代码保持一_(d)因此只做那些最需要的事，余下的部分则取决于明编写的代码和测试。XP 不保证h们d正确的事Q但它允思h们这样做。它?yu)这?#8220;极端”Ҏ(gu)以一U相互支持的方式l合hQ显著提高(sh)(jin)速度和有效性?/p>
|
|
XP 的十二种Ҏ(gu)Q如?2 所C）(j)其定义则。让我们仔细研究每一个方法来?#8220;执行 XP”表示什么有个更全面的理解?/p>
?2. XP 的十二种Ҏ(gu) 
规划{略
有些Z(x)指责 XP 是一U美其名的剽H，只是一牛仔在没有M规则的情况下一个系l拼凑在一赗错。XP 是ؓ(f)C多的几种承认(zhn)在开始时不可能事事通晓的方法之一。无论是用户q是开发h员都是随着目的进展过E才逐步?jin)解事物的。只有鼓励和信奉q种更改的方法才是有效方法。状态限定方法忽视更攏V?XP 则留?j)更攏V它們所用的Ҏ(gu)是“规划{略”Q一个由 Kent Beck 创造的概念?
q一Ҏ(gu)背后的主要思想是迅速地制定_略计划Q然后随着事物的不断清晰来逐步完善。规划策略的产物包括Q一堆烦(ch)引卡Q每一张都包含一个客L(fng)材，q些素材驱动目的P代；以及(qing)对下一两个发行版的_略计划Q如 Kent Beck ?Martin Fowler 在他们的 Planning Extreme Programming中描q的那样Q请参阅 参考资?/font>Q。让q种形式的计划得以发挥作用的关键因素是让用户做企业决{，让开发小l做技术决{。如果没有这一前提Q整个过E就?x)土崩瓦解?
开发小l要军_Q?/p>
- 估计开发一个素材要花多长时?
- 使用各种技术选项所p的成?
- 团队l织
- 每个素材?#8220;风险”
- q代中素材开发的序Q先开发风险最大的那一个可以减轻风险）(j)
客户需要决定：(x)
- 范围Q一个发行版的素材和每一ơP代的素材Q?
- 发行日期
- 优先U（Ҏ(gu)企业价值先开发哪些特性）(j)
规划l常发生。这P在客h开发h员学?fn)新事物的同Ӟ׃?f)他们调整计划提供?jin)频J机?x)?/p>
成对~程
使用 XPQ成对的开发h员编写所有品代码。这U方式听上去好象~Z效率。Martin Fowler _(d)“当h们说成对~程降低生力时Q我回答Q?#8216;那是因ؓ(f)大多数耗费旉的编E部分是靠输入来完成的?#8217;”实际上，成对~程无论在经还是其它方面都提供?jin)许多好处?x)
- 所有设计决{都牉|到至两个h?
- 臛_有两个h熟?zhn)pȝ的每一部分?
- 几乎不可能出C个h同时疏忽试或其它Q务?
- 改变各对的组合在可以在团队范围内传播知识?
- 代码Lp一人复查?
研究q显C成对的~程实际上比单独~程更有效（有关详细信息Q请参阅 参考资?/font> ?Alistair Cockburn ?Laurie Williams 所著的 The Costs and Benefits of Pair ProgrammingQ?
试
?XP 中有两种试Q?
- 单元试
- 验收试
开发h员在他们~写代码的同时编写单元测试。客户在他们定义?jin)素材后~写验收试。单元测试及(qing)时告诉开发h员系l在某一点上是否“工作”。验收测试告诉团队系l是否执行用户希望它执行的操作?/p>
假设团队使用的是?Java q样的面向对象语aQ开发h员在Z些方法编写代码之前ؓ(f)每种有可能失败的Ҏ(gu)~写单元试。然后他们编写够的代码使之能通过试。有时h们会(x)发现q有点奇怪。答案很单。编写测试首先ؓ(f)(zhn)提供：(x)
- 一l可能最完整的测?
- 可能能工作的最单的代码
- 代码意图的明景?
开发h员只有在通过所有单元测试后才可以将代码(g)入到源代码资源库中。单元测试开发h员有信心(j)怿他们的代码能够工作。这为其他开发h员留下线索，可以帮助他们理解最早的开发h员的意图Q实际上Q这是我们看到过的最好的文档Q。单元测试还l了(jin)开发h员勇气重新划分代码，因ؓ(f)试p|可以立刻告诉开发h员存在错误。应该将单元试自动化，q提供明的通过Q失败结果。xUnit 框架Q请参阅 参考资?/font> Q做到的q不止这些，因此大多?XP 组都用它们?
用户负责保每个素材都有验收试来确认它们。用户可以自q写测试、可以征募组l中的其他成员（例如 QA 人员或业务分析员Q编写它们，也可以将q两U方法结合v来。测试告诉他们系l是否具有应该具有的那些Ҏ(gu)，以及(qing)是否可以正确工作。理x(chng)况下Q用户在q代完成之前应该写好P代中那些素材的验收测试了(jin)。应该将验收试自动化，q要l常q行来确保开发h员在实现新特性时没有破坏M现有的特性。通常情况下，客户需要来自开发团队的某些帮助来编写验收测试。我们对一个项目开发一个可重用的自动验收测试框Ӟ可以让用户在单编辑器中输入他们的输入和所期望的输出。框架将输入转换?XML 文g、运行文件中的测试，然后为每个测试显C?#8220;通过”?#8220;p|”。客户喜Ƣ这一做法?/p>
不是所有验收测试都必须在所有情况下通过。问题是验收试帮助客户衡量目“完成”的情况如何。它们还可以让客戯(zhn)有x(chng)些事物是否可以发行的军_?/p>
重新划分
重新划分是在不更改功能性的前提下对代码加以改进。XP 组在进行重新划分时毫不手Y?
开发h员重新划分有两个重要时机Q实现特性之前和之后。开发h员尝试确定更改现有代码是否可以让新特性的开发更Ҏ(gu)。他们查看刚刚写好的代码Q看是否有方法可以对它进行简化。例如，如果他们认ؓ(f)有抽象的Z(x)Q就?x)进行重新划分来从具体实C除去重复的代码?/p>
XP (zhn)应该编写可能运行的最单的代码Q但同时也徏议?zhn)应该不断学?fn)。重新划分让(zhn)将学到的知识加入到代码中，同时又不?x)破坏测试。它使?zhn)的代码简l。这意味着它可以存在相当长的时间、ؓ(f)以后的开发h员引入更问题，qؓ(f)他们指引正确的方向?/p>
单的设计
XP 的诽谤者说该过E忽略了(jin)设计。事实不是这栗问题是重量型方法徏议?zhn)做的不过是提前完成大部分琐碎的设计Q务。这p是拍一张静(rn)态的地^U的照片Q静(rn)止不动，然后试M张如何到N里的完美的地图。XP 说设计不应该在事物将保持不变的前提下预先仓促(j)q行。XP 认ؓ(f)设计非常重要Q因此应该是一个持l的事务。我们L先尝试用能够工作的最单的设计Q然后随着现实的不断显现来更改它?
什么是可能工作的最单的设计Q它是符合以下条件的设计Q感?Kent Beck 为我们一一列出Q：(x)
- q行所有测?
- 不包含重复代?
- 明确陈述E序员对所有代码的意图
- 包含可能最的cdҎ(gu)
对简单设计的需求ƈ不是说所有设计都很小Q也不表C它们是无轻重的。它们只不过需要尽可能单，但是仍能工作。不要包括不使用的额外特性。我们称q样的事物ؓ(f) YAGNIQ表C?#8220;(zhn)将不需要它QYou Aren't Going to Need ItQ?#8221;不要?YAGNI 破坏(zhn)成功的Z(x)?/p>
集合体代码所有权
组中的M人都应该有权对代码进行更Ҏ(gu)改进它。每个h都拥有全部代码，q意味着每个人都对它负责。这U技术可以让Z寚w分代码进行必要的更改而不用经q代码拥有者个人的瓉。每个h都负责这一事实消除?jin)无代码所有权所带来的乱?
“每h拥有所有代?#8221;?#8220;没h拥有代码”的说法ƈ不一栗没人拥有代码时Qh们可以随处进行破坏而不必负M责Q。?XP _(d)“如果是?zhn)破坏的，应该?zhn)来弥补?#8221;我们有一些必d每次集成之前和之后运行的单元试。如果?zhn)破坏了(jin)某些事物，?zhn)要负责q行修补Q无论它位于代码的哪一部分。这需要极端规则。可能这是名UC带有“极端”的另一个原因?/p>
持箋(hu)的集?/strong>
l常q行代码集成可以帮助(zhn)避免集成梦。XP 团队在一天中集成?jin)代码几ơ，每次都在所有单元测试对pȝq行后执行?
传统Ҏ(gu)工作方式如下Q编写大量代码后执行一ơ大爆炸式的集成Q然后花费相当长的时间来Ҏ(gu)问题。这U笨拙的形式的确佉K目速度减缓。大爆炸式的集成l团队立卛_来大量问题，q且q些问题通常都有几百U可能的原因?/p>
如果l常q行集成QQ何特定集成失败的原因都会(x)非常明显Q以前运行过试Q因此错误一定是C物犯下的Q。用这U方法，当遇到问题时Q可能的原因q当有限。修改v来更Ҏ(gu)Q花的时间少得多Q团队保持最快速度前进?/p>
现场客户
要功能最理想QXP 组需要在现场有一位客h明确素材Qƈ做出重要的企业决{。开发h员是不允许单独做q些事情的。让客户随时在场可以消除开发h员等待决{时出现的瓶颈?
XP 不会(x)假装素材卡是开发h员(sh)付必要代码所需的唯一指示。素材是对以后在客户和开发h员(sh)间填写细节的对话的一Ҏ(gu)诺。与所有要求写在一个静(rn)态文档中不同Q其思想是进行面寚w的交，减少产生误解的机?x)?/p>
我们发现让客户在现场是可能最好的一U情形，但这不是解决问题的唯一Ҏ(gu)。底U是客户必须随时在需要回{问题和Ҏ(gu)企业价gؓ(f)团队提供指示时有I。如果客户ƈ非在现场专职陪伴团队的情况下p做到q些Q那很好。如果能和团队待在一Pq会(x)更方便，但只是徏议而已?/p>
发行版
发行版应该尽可能地小Q同时仍然提供够的企业价g证明它们值得?
只要觉得有意义就可以发布pȝ。这样就可能早为用h供了(jin)价|误住，今天的钱比明天的钱来得值钱Q。小发行版将为开发h员提供具体的反馈意见Q告诉他们哪些符合客户需要，哪些不符合客户需要。然后，组可以这些经验教训包括在其下一发行版的规划中?/p>
一?40 时
Kent Beck 说他希望“...每天早晨都感到有zd有激情，每天晚上都感到疲惫而满?#8221;一?40 时工作可以让?zhn)做到q一炏V确切的时数ƈ不重要，重要的是原则。长旉地持l工作会(x)扼杀工作l效。疲劳的开发h员(sh)(x)犯更多错误，从长期来_(d)比?#8220;正常”旉表进行的开发慢得多?
即开发h员可以在长时间很好工作，q也不意味着他们应该q样。最l他们会(x)厌倦，?x)离开他们的工作，或者生媄(jing)响他们工作W效的非工作问题。如果?zhn)打ؕ了(jin)h们的生活Q将?x)尝到它所带来的恶果。加班ƈ不是解决目问题的答案。实际上Q它是更大问题的症状。如果?zhn)要走向灭亡，无药可救?jin)?/p>
~码标准
拥有~码标准有两个目的：(x)
- 防止团队被一些例如事物没有以最大速度发展q种无关紧要的愚蠢争论搞得不知所措?
- 它支持其它方法?
如果没有~码标准Q重新划分代码会(x)更加困难Q按应当的频度交换对更困难，快速前q也更困难。目标应该是团队中没有h辨认得出是谁写的哪一部分代码。以团队为单位对某一标准达成协议Q然后遵守这一标准。目标不是创Z个事无巨l的规则列表Q而是提供确保?zhn)的代码可以清C的指导斚w。编码标准开始时应该很简单，然后Ҏ(gu)团队l验逐步q化。不要预先花费太多时间。创够工作的最单标准，然后逐步发展?/p>
pȝ比喻
体系l构是做什么用的？它提供了(jin)pȝ各种lg以及(qing)它们是如何交互的画面 -- 一U映，可以让开发h员(sh)(jin)解新的代码部分适合攑֜哪里?
XP 中的pȝ比喻与大多数Ҏ(gu)UC的体pȝ构差不多。比Mؓ(f)团队提供?jin)一致的画面Q他们可以用它来描述现有pȝ的工作方式、新部g适合的位|，以及(qing)它们应该采取的Ş式?/p>
重要的是要记住，关键要让每个人理解系l是如何l合在一L(fng)Q而不是美丽的比喻。有时?zhn)是无法惛_一个好的比喅R想到时太好了(jin)?/p>
|
|
整体大于各个部分之和。?zhn)可以实现单一Ҏ(gu)或一部分方法，比不使用MҎ(gu)得到更大收益。但(zhn)只能在实现所有方法的情况下获得最大收益，因ؓ(f)它们的力量来自它们之间的交互?/p>
最初时按照书籍来执?XPQ作为基准。一旦理解了(jin)如何q行交互Q就拥有?jin)将它们适应于自w环境所需的知识。请CQ?#8220;q行 XP”不是目的Q而是到达l点的一U手Dc(din)目标是快速地开发高UY件。如果?zhn)的过E有一些变异，已称不上是在q行 XPQ但l果仍能让?zhn)战胜所有竞争对手，(zhn)已l成功了(jin)?/p>
|
|
坦率地说QXPQ或者Q何其它灵zL法）(j)Ҏ(gu)׃重要。它能够产生?l果 才是关键。如果如 XP q样的灵zL式可以帮助?zhn)更快地开发更好的软g而少受痛苦，那么它值得考虑?
q记得我们在q篇文章开始时提到的那些o(h)人生畏的数字吗？我们怿使用 XP 开发面向对象Y件可以有Z(x)它们变得更好。目前我们的l验已经证实?jin)这一信念?/p>
- (zhn)可以参阅本文在 developerWorks 全球站点上的 英文原文.
- ?RoleModel Software ?XP Portal 中了(jin)解有?XP 的详l信息?
- 可以?Alistair Cockburn ?Laurie Williams (XP2000 submission, 2000) 所著的 The Costs and Benefits of Pair Programming 中了(jin)解到有关成对~程所h的经方面的意义?
- ?Pairprogramming.com 上可以知道成对编E的常规详细信息?
- 下蝲 xUnit 试工具?
- 如果(zhn)希望了(jin)解有?XP 的详l信息，请务必选取一本本书中引用的书c：(x)
- Planning Extreme Programming Q由 Kent Beck ?Martin Fowler ?(Addison-Wesley, 2000)
- Extreme Programming Explained: Embrace Change Q由 Kent Beck ?(Addison-Wesley, 1999)
- Leading the Revolution ?Gary Hamel ?(Harvard Business School, 2000)
- Jeff Canna 有关 单元和功能测?/font> 的文章（developerWorksQ?001 q?3 月）(j)?XP 哲学用在试上?
|
||
|
|
|
Roy W. Miller ?RoleModel Software, Inc 的Y件开发h员。在 RoleModel 期间QRoy 开发了(jin)Z Java/XML 的自动验收测试框Ӟqؓ(f) Dallas Semiconductor ?TINI Java q_创徏?jin)几个应用的原型。在加盟 RoleModel 之前Q他?Andersen ConsultingQ现在是 AccentureQ中服务?jin)六q_(d)用过他们的专用重量型商业集成Ҏ(gu) (MIB) ?qing)其变?sh)。自从加?RoleModel 后，他获得了(jin)许多有关 XP 以及(qing)对该Ҏ(gu)的本地适应的经验。Roy 与他人合著了(jin) Addison-Wesley XP pd中的一本书Q?XP Applied Q将?2001 q?10 月出版）(j)Qƈ是在 XP2001 "Business of XP" 展示?x)上的一名特邀(g)专题讨论组成员。可以通过 rmiller@rolemodelsoft.com ?Roy 联系? |
|
||
|
|
|
Christopher T. Collins ?RoleModel Software, Inc 的高UY件开发h员。在 RoleModel 期间QChris 参与?jin)运行将q两q的一?XP 目Qؓ(f)新的摩托|拉蜂窝式电(sh)话^台开发了(jin)一个嵌入式 Java 应用E序Qƈ?JUnit UL?Sun ?J2ME q_上运行。在加盟 RoleModel 之前Q他׃(jin) 5 q的旉使用许多不同的语aZ些组l开发YӞ最q的一ơ是为美国国防部开发应用程序。他拥有使用和适应涉及(qing)几种灉|和重量型的不同开发方法的l验Q包?RUP ?XP。Chris 拥有国西佛(jng)|里辑֤学计机U学和Y件工E的士学位Q目前在北卡|来U_立大学教?Java ~程评。他曾是杜克大学有关 XP 的特邀(g)演讲人，q将?XP2001 上介l有兌E适应的论文。通过 ccollins@rolemodelsoft.com ?Chris 联系? |
]]>