XP英华:何使Java项目得到更大乐成
副标题#e#
利用 Java 语言所举办的面向工具编程变得空前普及。它使软件开拓产生了某种水平上的厘革，但最近的研究表白，有半数的软件开拓项目滞后，而三分之一的项目则超出预算。问题不在于技能，而是开拓软件所利用的要领。所谓的“轻量型”或“机动”方法，与如 Java 这样的面向工具语言的威力和机动性团结起来，提供了一种很有意思的办理方案。最常见的机动方法称为极度编程（Extreme Programming）可能 XP，但很多人并不真正相识它。对 Java 项目利用 XP 可以大大增加乐成的时机。本文提供了 XP 的概述，并表明白它为什么很重要 — 不是传言，也没有骗局。
在已往的十年中，CEO 们在发生稳步增加的收入方面面对庞大的压力。他们通过在很多方面采纳一系列办法来办理这一问题，譬喻缩小公司局限、外包、再工程、企业资源筹划 (ERP) 等等。这些对低效率的办理法子让 S&P 500 中的很多企业在 90 年月末可以或许持续几年保持两位数的收入增长。但这种方法也带来了一些负面影响。
在 Gary Hamel 所著的 Leading the Revolution（请参阅参考资料）一书中，他声称已有一些迹象证明传统企业模式的优势已不那么明明。我们必需找到一些替代要领来为收入的一连增长提供动力。他发起独一能让公司继承增长的步伐是举办一次彻底的创新。我们认为在软件开拓规模中尤其需要这样。
企业问题
假如利用尺度软件开拓要领，那么纵然在 Java 平台长举办开拓，也要做好失望的筹备。如图 1 所示，最近的研究表白，有一半项目将滞后，而三分之一的项目将高出预算。这一猜测比 1979 年由美国总审计局的研究功效好不了几多。
图 1. 软件项目乐成和失败，已往和此刻
假如我们但愿这些数字有显著提高，则需要彻底创新的要领来开拓软件。有两个主要因素影响现有的要领：
1、恐惊失败
2、对软件本质的误解
没有人规划失败。具有嘲讽意味的是为使失败最小化而建设的要领是失败的。对软件的误解是问题的来源。惊骇实际上只是一种症状。现有的要领是由那些有精采愿望但健忘了软件中的“软”的那些智慧人所建设的。他们假定开拓软件就象造桥。因此他们从各类设计类型中警惕了一些合用于“硬”物体（譬喻桥梁）的最优要领。功效是基于 Big Design Up-front (BDUF) 思想的反应痴钝的开拓要领，软件不堪一击，人们无法利用它们。
一种办理方案：机动要领
最近产生了一些转变，从所谓的“重量型”要领转向了“轻量型”或“机动”要领，譬喻 Crystal 要领、适应性软件开拓和（当前最风行的）XP。所有这些进程都有这样一个事实，即需要人们配合来开拓软件。乐成的软件进程必需将人们的优点最大化，将他们的缺点最小化，因为利益和缺点毋庸质疑都存在。在我们看来，XP 最精彩的处地址于它可以或许办理所有影响介入人员的互补气力。
XP 提供了十年来最大的一次时机，给软件开拓进程带来彻底厘革。就象 Peopleware 作家 Tom DeMarco 所说，“XP 是当今我们所处规模中最重要的一项举动。估量它对付今朝一代的重要性就象 SEI 及其本领成熟度模子对上一代的重要性一样。”
XP 划定了一组焦点代价和要领，可以让软件开拓人员发挥他们的专长：编写代码。XP 消除了大大都重量型进程的不须要产品，通过减慢开拓速度、淹灭开拓人员的精神（譬喻干特图、状态陈诉，以及多卷需求文档）从方针偏离。我们认识到一个称为“极度编程”的对象大概很难作为正式的开拓进程推荐给打点层，但假如您的公司从事软件行业，您应该辅佐打点层绕过其名称认识到 XP 可以提供的竞争优势。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一书中归纳综合了 XP 的焦点代价（请参阅参考资料）。我们对它们举办了总结：
交换 项目标问题往往可以追溯到或人在某个时刻没有和其他人一起磋商某些重要问题上。利用 XP，不交换是不行能的事。
简朴 XP 发起您老是尽大概环绕进程和编写代码做最简朴的工作。凭据 Beck 的说法，“XP 就是赌博。它赌博本日最好做些简朴的事…而不是做更巨大但大概永远也不会用到的事。”
反馈 更早和常常来自客户、团队和实际最终用户的详细反馈意见为您提供更多的时机来调解您的气力。反馈可以让您掌握住正确的偏向，少走弯路。
勇气 勇气存在于其它三个代价的情况中。它们彼此支持。需要勇气来相信一路上详细反馈比预先知道每样事物来得更好。需要勇气来在大概袒露您的蒙昧时与团队中其他人交换。需要勇气来使系统尽大概简朴，将来日诰日的抉择推到来日诰日做。而假如没有简朴的系统、没有不绝的交换来扩展常识、没有把握偏向所依赖的反馈，勇气也就失去了依靠。
#p#副标题#e#
#p#分页标题#e#
XP 的要领将这些代价转换成开拓人员天天应做的工作。这里没什么新鲜内容。多年以来，行业认识到 XP 要领是“最优要领”。实际上，XP 中的“极度”来自两方面：
XP 采纳颠末证明的业界最优要领并将其发挥到极致。
XP 将这些要领以某种方法举办团结，使它们发生的功效大于各部门的总和。
这是奈何的情景呢？代码复查是个好的做法，因此始终通过成对地编写代码来做到。测试也是个好的做法，因此老是通过在编写代码之前编写测试来做到。文档很少与代码保持一致，因此只做那些最需要的事，余下的部门则取决于明晰编写的代码和测试。XP 不担保人们总做正确的事，但它答允人们这样做。它将这些“极度”要领以一种彼此支持的方法团结起来，显著提高了速度和有效性。
XP 的十二种要领
XP 的十二种要领（如图 2 所示）将其界说为法则。让我们仔细研究每一个要领来对“执行 XP”暗示什么有个更全面的领略。
图 2. XP 的十二种要领
筹划计策
有些人会指责 XP 是一种美其名的剽窃，只是一群牛仔在没有任何法则的环境下将一个系统拼凑在一起。错。XP 是为数不多的几种认可您在开始时不行能事事通晓的要领之一。无论是用户照旧开拓人员都是跟着项目标希望进程才慢慢相识事物的。只有勉励和信奉这种变动的要领才是有效要领。状态限定要领忽视变动。而 XP 则把稳变动。它倾听所用的要领就是“筹划计策”，一个由 Kent Beck 缔造的观念。
这一要领背后的主要思想是迅速地拟定大致打算，然后跟着事物的不绝清晰来慢慢完善。筹划计策的产品包罗：一堆索引卡，每一张都包括一个客户素材，这些素材驱动项目标迭代；以及对下一两个刊行版的大致打算，如 Kent Beck 和 Martin Fowler 在他们的 Planning Extreme Programming 中描写的那样（请参阅参考资料）。让这种形式的打算得以发挥浸染的要害因素是让用户做企业决定，让开拓小组做技能决定。假如没有这一前提，整个进程就会土崩解体。
开拓小组要抉择：
预计开拓一个素材要花多长时间
利用各类技能选项所耗费的本钱
团队组织
每个素材的“风险”
迭代中素材开拓的顺序（先开拓风险最大的那一个可以减轻风险）
客户需要抉择：
范畴（一个刊行版的素材和每一次迭代的素材）
刊行日期
优先级（按照企业代价先开拓哪些特性）
筹划常常产生。这样，在客户或开拓人员进修新事物的同时，就为他们调解打算提供了频繁时机。
成对编程
利用 XP，成对的开拓人员编写所有产物代码。这种方法听上去好象缺乏效率。Martin Fowler 说，“当人们说成对编程低落出产力时，我答复，‘那是因为大大都淹灭时间的编程部门是靠输入来完成的。’”实际上，成对编程无论在经济照旧其它方面都提供了很多长处：
所有设计决定都牵涉到至少两小我私家。
至少有两小我私家熟悉系统的每一部门。
险些不行能呈现两小我私家同时疏忽测试或其它任务。
改变各对的组合在可以在团队范畴内流传常识。
代码老是由至少一人复查。
研究还显示成对的编程实际上比单独编程更有效（有关具体信息，请参阅参考资料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）。
测试
在 XP 中有两种测试：
1、单位测试
2、验收测试
开拓人员在他们编写代码的同时编写单位测试。客户在他们界说了素材后编写验收测试。单位测试实时汇报开拓人员系统在某一点上是否“事情”。验收测试汇报团队系统是否执行用户但愿它执行的操纵。
假设团队利用的是如 Java 这样的面向工具语言，开拓人员在为一些要领编写代码之前为每种有大概失败的要领编写单位测试。然后他们编写足够的代码使之能通过测试。有时人们会发明这有点奇怪。谜底很简朴。编写测试首先为您提供：
一组大概最完整的测试
大概能事情的最简朴的代码
代码意图的明晰情形
#p#分页标题#e#
开拓人员只有在通过所有单位测试后才可以将代码检入到源代码资源库中。单位测试使开拓人员有信心相信他们的代码可以或许事情。这为其他开拓人员留下线索，可以辅佐他们领略最早的开拓人员的意图（实际上，这是我们看到过的最好的文档）。单位测试还给了开拓人员勇气从头分别代码，因为测试失败可以立即汇报开拓人员存在错误。应该将单位测试自动化，并提供明晰的通过／失败功效。xUnit 框架（请参阅参考资料）做到的远不止这些，因此大大都 XP 小组都利用它们。
用户认真确保每个素材都有验收测试来确认它们。用户可以本身编写测试、可以征募组织中的其他成员（譬喻 QA 人员或业务阐明员）编写它们，也可以将这两种要领团结起来。测试汇报他们系统是否具有应该具有的那些特性，以及是否可以正确事情。抱负环境下，用户在迭代完成之前就应该写好迭代中那些素材的验收测试了。应该将验收测试自动化，并要常常运行来确保开拓人员在实现新特性时没有粉碎任何现有的特性。凡是环境下，客户需要来自开拓团队的某些辅佐来编写验收测试。我们对一个项目开拓一个可重用的自动验收测试框架，可以让用户在简朴编辑器中输入他们的输入和所期望的输出。框架将输入转换成 XML 文件、运行文件中的测试，然后为每个测试显示“通过”或“失败”。客户喜欢这一做法。
不是所有验收测试都必需在所有环境下通过。问题是验收测试辅佐客户权衡项目“完成”的环境如何。它们还可以让客户获悉有关某些事物是否可以刊行的抉择。
从头分别
从头分别是在不变动成果性的前提下对代码加以改造。XP 小组在举办从头分别时绝不手软。
开拓人员从头分别有两个重要机缘：实现特性之前和之后。开拓人员实验确定变动现有代码是否可以让新特性的开拓更容易。他们查察方才写好的代码，看是否有要领可以对它举办简化。譬喻，假如他们认为有抽象的时机，就会举办从头分别来从详细实现中撤除反复的代码。
XP 发起您应该编写大概运行的最简朴的代码，但同时也发起您应该不绝进修。从头分别让您将学到的常识插手到代码中，同时又不会粉碎测试。它使您的代码简洁。这意味着它可以存在相当长的时间、为今后的开拓人员引入更少问题，并为他们指引正确的偏向。
简朴的设计
XP 的离间者说该进程忽略了设计。事实不是这样。问题是重量型要领发起您做的不外是提前完成大部门琐碎的设计任务。这就象是拍一张静态的地平线的照片，静止不动，然后实验画一张如何达到哪里的完美的舆图。XP 说设计不该该在事物将保持稳定的前提下预先急遽举办。XP 认为设计很是重要，因此应该是一个一连的事务。我们老是先实验利用可以或许事情的最简朴的设计，然后跟着现实的不绝显现来变动它。
什么是大概事情的最简朴的设计？它是切合以下条件的设计（感激 Kent Beck 为我们一一列出）：
运行所有测试
不包括反复代码
明晰告诉措施员对所有代码的意图
包括尽大概最少的类和要领
对简朴设计的需求并不是说所有设计都很小，也不暗示它们是无足轻重的。它们只不外需要尽大概简朴，可是仍能事情。不要包罗不利用的特别特性。我们称这样的事物为 YAGNI，暗示“您将不需要它（You Aren’t Going to Need It）。”不要让 YAGNI 粉碎您乐成的时机。
荟萃体代码所有权
小组中的任何人都应该有权对代码举办变动来改造它。每小我私家都拥有全部代码，这意味着每小我私家都对它认真。这种技能可以让人们对部门代码举办须要的变动而不消颠末代码拥有者小我私家的瓶颈。每小我私家都认真这一事实消除了无代码所有权所带来的杂乱。
“每人拥有所有代码”与“没人拥有代码”的说法并纷歧样。没人拥有代码时，人们可以到处举办粉碎而不必负任何责任。而 XP 说，“假如是您粉碎的，应该您来补充。”我们有一些必需在每次集成之前和之后运行的单位测试。假如您粉碎了某些事物，您要认真举办修补，无论它位于代码的哪一部门。这需要极度法则。大概这是名称中带有“极度”的另一个原因。
一连的集成
常常举办代码集成可以辅佐您制止集成梦魇。XP 团队在一天中集成了代码屡次，每次都在所有单位测试对系统运行后执行。
#p#分页标题#e#
传统要领事情方法如下：编写大量代码后执行一次大爆炸式的集成，然后耗费相当长的时间来纠正问题。这种鸠拙的形式简直使项目速度减缓。大爆炸式的集成给团队当即带来大量问题，而且这些问题凡是都有几百种大概的原因。
假如常常举办集成，任何特定集成失败的原因城市很是明明（以前运行过测试，因此错误必然是新事物犯下的）。利用这种要领，当碰着问题时，大概的原因就相当有限。修改起来更容易，花的时间少得多，使团队保持最快速度前进。
现场客户
要使成果最抱负，XP 小组需要在现场有一位客户来明晰素材，并做出重要的企业决定。开拓人员是不答允单独做这些工作的。让客户随时在场可以消除开拓人员期待决定时呈现的瓶颈。
XP 不会冒充素材卡是开拓人员交付须要代码所需的独一指示。素材是对今后在客户和开拓人员之间填写细节的对话的一项理睬。与将所有要求写在一个静态文档中差异，其思想是举办面劈面的交换，淘汰发生误解的时机。
我们发明让客户在现场是大概最好的一种景象，但这不是办理问题的独一方案。底线是客户必需随时在需要答复问题和按照企业代价为团队提供指示时有空。假如客户并非在现场专职伴随团队的环境下就能做到这些，那很好。假如能和团队待在一起，这会更利便，但只是发起罢了。
小刊行版
刊行版应该尽大概地小，同时仍然提供足够的企业代价以证明它们值得。
只要以为有意义就可以宣布系统。这样就尽大概早为用户提供了代价（请记着，本日的钱比来日诰日的钱来得值钱）。小刊行版将为开拓人员提供详细的反馈意见，汇报他们哪些切合客户需要，哪些不切合客户需要。然后，小组可以将这些履历教导包罗在其下一刊行版的筹划中。
一周 40 小时
Kent Beck 说他但愿“…天天早晨都感想有活力有豪情，天天晚上都感想疲劳而满意。”一周 40 小时事情可以让您做到这一点。确切的小时数并不重要，重要的是原则。长时间地一连事情会抹杀事情绩效。疲惫的开拓人员会犯更多错误，从恒久来说，将比按“正常”时间表举办的开拓慢得多。
纵然开拓人员可以在长时间很功德情，这也不料味着他们应该这样。最终他们会厌倦，会分开他们的事情，可能发生影响他们事情绩效的非事情问题。假如您打乱了人们的糊口，将会尝到它所带来的恶果。加班并不是办理项目问题的谜底。实际上，它是更大问题的症状。假如您要走向死亡，就无药可救了。
编码尺度
拥有编码尺度有两个目标：
防备团队被一些譬喻事物没有以最大速度成长这种无关紧急的愚蠢争论搞得不知所措。
它支持其它要领。
假如没有编码尺度，从头分别代码会越发坚苦，按该当的频度互换对更坚苦，快速前进也更坚苦。方针应该是团队中没有人辨认得出是谁写的哪一部门代码。以团队为单元对某一尺度告竣协议，然后遵守这一尺度。方针不是建设一个事无大小的法则列表，而是提供将确保您的代码可以清晰交换的指导目的。编码尺度开始时应该很简朴，然后按照团队履历慢慢进化。不要预先耗费太多时间。建设可以或许事情的最简朴尺度，然后慢慢成长。
系统比喻
体系布局是做什么用的？它提供了系统各类组件以及它们是如何交互的画面 — 一种映射，可以让开拓人员相识新的代码部门适合放在那边。
XP 中的系统比喻与大大都要领称作的体系布局差不多。比喻为团队提供了一致的画面，他们可以用它来描写现有系统的事情方法、新部件适合的位置，以及它们应该采纳的形式。
重要的是要记着，要害要让每小我私家领略系统是如何组合在一起的，而不是瑰丽的比喻。有时您就是无法想到一个好的比喻。想到时就太好了。
一起事情的要领
整体大于各个部门之和。您可以实现单一要领或一小部门要领，比不利用任何要领获得更大收益。但您只能在实现所有要领的环境下得到最大收益，因为它们的气力来自它们之间的交互。
最初时凭据书籍来执行 XP，作为基准。一旦领略了如何举办交互，就拥有了将它们适应于自身情况所需的常识。请记着，“举办 XP”不是目标，而是达到终点的一种手段。方针是快速地开拓高级软件。假如您的进程有一些变异，已称不上是在举办 XP，但功效仍能让您战胜所有竞争敌手，您已经乐成了。
为什么 XP 很重要
坦率地说，XP（可能任何其它机动要领）基础就不重要。它可以或许发生的功效才是要害。假如如 XP 这样的机动方法可以辅佐您更快地开拓更好的软件而少受疾苦，那么它值得思量。
#p#分页标题#e#
还记得我们在这篇文章开始时提到的那些令人生畏的数字吗？我们相信利用 XP 开拓面向工具软件可以有时机将它们变得更好。今朝我们的履历已经证实了这一信念。
