快捷搜索:

XP精华-如何使 Java 项目获得更大成功

XP 英华

若何使 Java 项目得到更大年夜成功

Roy W. Miller (rmiller@rolemodelsoft.com)

软件开拓职员,RoleModel Software, Inc.

Christopher T. Collins (ccollins@rolemodelsoft.com)

高档软件开拓职员,RoleModel Software, Inc.

2001 年 3 月

内容:

企业问题

一种办理规划:机动措施

XP 的 12 种措施

一路事情的措施

为什么 XP 很紧张

参考资料

关于作者

评价这篇文章

应用 Java 说话所进行的面向工具编程变得空前遍及。它使软件开拓发生了某种程度上的厘革,但近来的钻研注解,有折半的软件开拓项目滞后,而三分之一的项目则越过预算。问题不在于技巧,而是开拓软件所应用的措施。所谓的“轻量型”或“机动”要领,与如 Java 这样的面向工具说话的威力和机动性结合起来,供给了一种很故意思的办理规划。最常见的机动要领称为极度编程(Extreme Programming)或者 XP,但许多人并不真正懂得它。对 Java 项目应用 XP 可以大年夜大年夜增添成功的时机。本文供给了 XP 的概述,并说清楚明了它为什么很紧张 -- 不是传言,也没有骗局。

在以前的十年中,CEO 们在孕育发生稳步增添的收入方面面临伟大年夜的压力。他们经由过程在许多方面采取一系枚举措来办理这一问题,例如缩小公司规模、外包、再工程、企业资本筹划 (ERP) 等等。这些对低效率的办理步伐让 S&P 500 中的许多企业在 90 年代末能够继续几年维持两位数的收入增长。但这种要领也带来了一些负面影响。

在 Gary Hamel 所著的 Leading the Revolution(请参阅参考资料)一书中,他声称已有一些迹象证实传统企业模式的上风已不那么显着。我们必须找到一些替代措施来为收入的持续增长供给动力。他建议独一能让公司继承增长的法子是进行一次彻底的立异。我们觉得在软件开拓领域中尤其必要这样。

企业问题

假如应用标准软件开拓措施,那么纵然在 Java 平台长进行开拓,也要做好失望的筹备。如图 1 所示,近来的钻研注解,有一半项目将滞后,而三分之一的项目将跨越预算。这一推想比 1979 年由美国总审计局的钻研结果好不了若干。

图 1. 软件项目成功和掉败,以前和现在

假如我们盼望这些数字有显明前进,则必要彻底立异的措施来开拓软件。有两个主要身分影响现有的措施:

畏惧掉败

对软件本色的误解

没有人盘算掉败。具有讥诮意味的是为使掉败最小化而创建的措施是掉败的。对软件的误解是问题的根源。畏怯实际上只是一种症状。现有的措施是由那些有优越希望但忘怀了软件中的“软”的那些智慧人所创建的。他们假定开拓软件就象造桥。是以他们从各类设计规范中借鉴了一些适用于“硬”物体(例如桥梁)的最优措施。结果是基于 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 便是打赌。它打赌本日最好做些简单的事...而不是做更繁杂但可能永世也不会用到的事。”

反馈。 更早和常常来自客户、团队和实际终极用户的详细反馈意见为您供给更多的时机来调剂您的气力。反馈可以让您把握住精确的偏向,少走弯路。

勇气。 勇气存在于其它三个代价的情况中。它们互相支持。必要勇气来信托一起上详细反馈比预先知道每样事物来得更好。必要勇气来在可能裸露您的蒙昧时与团队中其他人交流。必要勇气来使系统尽可能简单,未翌日的抉择推到翌日做。而假如没有简单的系统、没有赓续的交流来扩展常识、没有掌握偏向所依附的反馈,勇气也就掉去了寄托。

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 中有两种测试:

单元测试

验收测试

开拓职员在他们编写代码的同时编写单元测试。客户在他们定义了素材后编写验收测试。单元测试及时奉告开拓职员系统在某一点上是否“事情”。验收测试奉告团队系统是否履行用户盼望它履行的操作。

假设团队应用的是如 Java 这样的面向工具说话,开拓职员在为一些措施编写代码之前为每种有可能掉败的措施编写单元测试。然后他们编写足够的代码使之能经由过程测试。无意偶尔人们会发明这有点稀罕。谜底很简单。编写测试首先为您供给:

一组可能最完备的测试

可能能事情的最简单的代码

代码意图的明确天气

开拓职员只有在经由过程所有单元测试后才可以将代码检入到源代码资本库中。单元测试使开拓职员有信心信托他们的代码能够事情。这为其他开拓职员留下线索,可以赞助他们理解最早的开拓职员的意图(实际上,这是我们看到过的最好的文档)。单元测试还给了开拓职员勇气从新划分代码,由于测试掉败可以立即奉告开拓职员存在差错。应该将单元测试自动化,并供给明确的经由过程/掉败结果。xUnit 框架(请参阅参考资料)做到的远不止这些,是以大年夜多半 XP 小组都应用它们。

用户认真确保每个素材都有验收测试来确认它们。用户可以自己编写测试、可以征募组织中的其他成员(例如 QA 职员或营业阐发员)编写它们,也可以将这两种措施结合起来。测试奉告他们系统是否具有应该具有的那些特点,以及是否可以精确事情。抱负环境下,用户在迭代完成之前就应该写好迭代中那些素材的验收测试了。应该将验收测试自动化,并要常常运行来确保开拓职员在实现新特点时没有破坏任何现有的特点。平日环境下,客户必要来自开拓团队的某些赞助来编写验收测试。我们对一个项目开拓一个可重用的自动验收测试框架,可以让用户在简单编辑器中输入他们的输入和所期望的输出。框架将输入转换成 XML 文件、运行文件中的测试,然后为每个测试显示“经由过程”或“掉败”。客户爱好这一做法。

不是所有验收测试都必须在所有环境下经由过程。问题是验收测试赞助客户衡量项目“完成”的环境若何。它们还可以让客户获悉有关某些事物是否可以发行的抉择。

从新划分

从新划分是在不变动功能性的条件下对代码加以改进。XP 小组在进行从新划分时绝不手软。

开拓职员从新划分有两个紧张机会:实现特点之前和之后。开拓职员考试测验确定变动现有代码是否可以让新特点的开拓更轻易。他们查看刚刚写好的代码,看是否有措施可以对它进行简化。例如,假如他们觉得有抽象的时机,就会进行从新划分来从详细实现中撤除重复的代码。

XP 建议您应该编写可能运行的最简单的代码,但同时也建议您应该赓续进修。从新划分让您将学到的常识加入到代码中,同时又不会破坏测试。它使您的代码简练。这意味着它可以存在相称长的光阴、为今后的开拓职员引入更少问题,并为他们指引精确的偏向。

简单的设计

XP 的诬蔑者说该历程轻忽了设计。事实不是这样。问题是重量型措施建议您做的不过是提前完成大年夜部分啰唆的设计义务。这就象是拍一张静态的地平线的照片,静止不动,然后考试测验画一张若何到达那里的完美的舆图。XP 说设计不应该在事物将维持不变的条件下预先仓匆匆进行。XP 觉得设计异常紧张,是以应该是一个持续的事务。我们老是先考试测验应用能够事情的最简单的设计,然后跟着现实的赓续显现来变动它。

什么是可能事情的最简单的设计?它是相符以下前提的设计(谢谢 Kent Beck 为我们逐一列出):

运行所有测试

不包孕重复代码

明确述说法度榜样员对所有代码的意图

包孕尽可能起码的类和措施

对简单设计的需求并不是说所有设计都很小,也不表示它们是无足轻重的。它们只不过必要尽可能简单,然则仍能事情。不要包括不应用的额外特点。我们称这样的事物为 YAGNI,表示“您将不必要它(You Aren´t Going to Need It)。”不要让 YAGNI 破坏您成功的时机。

聚拢体代码所有权

小组中的任何人都应该有权对代码进行变动来改进它。每小我都拥有整个代码,这意味着每小我都对它认真。这种技巧可以让人们对部分代码进行需要的变动而不用颠末代码拥有者小我的瓶颈。每小我都认真这一事实打消了无代码所有权所带来的纷乱。

“每人拥有所有代码”与“没人拥有代码”的说法并不一样。没人拥有代码时,人们可以随处进行破坏而不必负任何责任。而 XP 说,“假如是您破坏的,应该您来增补。”我们有一些必须在每次集成之前和之后运行的单元测试。假如您破坏了某些事物,您要认真进行修补,无论它位于代码的哪一部分。这必要极度规则。可能这是名称中带有“极度”的另一个缘故原由。

持续的集成

常常进行代码集成可以赞助您避免集成梦魇。XP 团队在一天中集成了代码几回,每次都在所有单元测试对系统运行后履行。

传统措施事情要领如下:编写大年夜量代码后履行一次大年夜爆炸式的集成,然后花费相称长的光阴来改正问题。这种愚蠢的形式切实着实使项目速率减缓。大年夜爆炸式的集成给团队急速带来大年夜量问题,并且这些问题平日都有几百种可能的缘故原由。

假如常常进行集成,任何特定集成掉败的缘故原由都邑异常显着(曩昔运行过测试,是以差错必然是新事物犯下的)。应用这种措施,当碰到问题时,可能的缘故原由就相称有限。改动起来更轻易,花的光阴少得多,使团队维持最快速率提高。

现场客户

要使功能最抱负,XP 小组必要在现场有一位客户来明确素材,并做出紧张的企业决策。开拓职员是不容许零丁做这些工作的。让客户随时在场可以打消开拓职员等待决策时呈现的瓶颈。

XP 不会装作素材卡是开拓职员交付需要代码所需的独一唆使。素材是对今后在客户和开拓职员之间填写细节的对话的一项允诺。与将所有要求写在一个静态文档中不合,其思惟是进行面对面的交流,削减孕育发生误解的时机。

我们发明让客户在现场是可能最好的一种情形,但这不是办理问题的独一规划。底线是客户必须随时在必要回答问题和根据企业代价为团队供给唆使时有空。假如客户并非在现场专职陪伴团队的环境下就能做到这些,那很好。假如能和团队待在一路,这会更方便,但只是建议而已。

小发行版

发行版应该尽可能地小,同时仍旧供给足够的企业代价以证实它们值得。

只要感觉故意义就可以宣布系统。这样就尽可能早为用户供给了代价(请记着,本日的钱比翌日的钱来得值钱)。小发行版将为开拓职员供给详细的反馈意见,奉告他们哪些相符客户必要,哪些不相符客户必要。然后,小组可以将这些履历教训包括在其下一发行版的筹划中。

一周 40 小时

Kent Beck 说他盼望“...天天凌晨都认为有生气愿望有激情,天天晚上都认为疲倦而满意。”一周 40 小时事情可以让您做到这一点。确切的小时数并不紧张,紧张的是原则。长光阴地持续事情会扼杀事情绩效。疲惫的开拓职员会犯更多差错,从经久来说,将比按“正常”光阴表进行的开拓慢得多。

纵然开拓职员可以在长光阴很好事情,这也不料味着他们应该这样。终极他们会厌倦,会脱离他们的事情,或者孕育发生影响他们事情绩效的非事情问题。假如您打乱了人们的生活,将会尝到它所带来的恶果。加班并不是办理项目问题的谜底。实际上,它是更大年夜问题的症状。假如您要走向灭亡,就无药可救了。

编码标准

拥有编码标准有两个目的:

防止团队被一些例如事物没有以最大年夜速率成长这种无关紧要的愚笨争辩搞得不知所措。

它支持其它措施。

假如没有编码标准,从新划分代码会加倍艰苦,按该当的频度互换对更艰苦,快速提高也更艰苦。目标应该是团队中没有人辨认得出是谁写的哪一部分代码。以团队为单位对某一标准杀青协议,然后遵守这一标准。目标不是创建一个事无巨细的规则列表,而是供给将确保您的代码可以清晰交流的指示方针。编码标准开始时应该很简单,然后根据团队履历慢慢进化。不要预先花费太多光阴。创建能够事情的最简单标准,然后慢慢成长。

系统比喻

体系布局是做什么用的?它供给了系统各类组件以及它们是若何交互的画面 -- 一种映射,可以闪开拓职员懂得新的代码部分得当放在哪里。

XP 中的系统比喻与大年夜多半措施称作的体系布局差不多。比喻为团队供给了同等的画面,他们可以用它来描述现有系统的事情要领、新部件得当的位置,以及它们应该采取的形式。

紧张的是要记着,关键要让每小我理解系统是若何组合在一路的,而不是标致的比喻。无意偶尔您便是无法想到一个好的比喻。想到时就太好了。

一路事情的措施

整体大年夜于各个部分之和。您可以实现单一措施或一小部分措施,比不应用任何措施获得更大年夜收益。但您只能在实现所有措施的环境下得到最大年夜收益,由于它们的气力来自它们之间的交互。

最初时按照册原本履行 XP,作为基准。一旦理解了若何进行交互,就拥有了将它们适应于自身情况所需的常识。请记着,“进行 XP”不是目的,而是到达终点的一种手段。目标是快速地开拓高档软件。假如您的历程有一些变异,已称不上是在进行 XP,但结果仍能让您战胜所有竞争对手,您已经成功了。

为什么 XP 很紧张

坦率地说,XP(或者任何其它机动措施)根本就不紧张。它能够孕育发生的结果才是关键。假如如 XP 这样的机动要领可以赞助您更快地开拓更好的软件而少受苦楚,那么它值得斟酌。

还记得我们在这篇文章开始时提到的那些令人生畏的数字吗?我们信托应用 XP 开拓面向工具软件可以有时机将它们变得更好。今朝我们的履历已经证明了这一信念。

参考资料

在 RoleModel Software 的 XP Portal 中懂得有关 XP 的具体信息。

可以在 Alistair Cockburn 和 Laurie Williams (XP2000 submission, 2000) 所著的 The Costs and Benefits of Pair Programming 中懂得到有关成对编程所具有的经济方面的意义。

在 Pairprogramming.com 上可以知道成对编程的老例具体信息。

下载 xUnit 测试对象。

假如您盼望懂得有关 XP 的具体信息,请务必拔取一本本书中引用的册本:

Planning Extreme Programming,由 Kent Beck 和 Martin Fowler 著 (Addison-Wesley, 2000)

Extreme Programming Explained: Embrace Change,由 Kent Beck 著 (Addison-Wesley, 1999)

Leading the Revolution 由 Gary Hamel 著 (Harvard Business School, 2000)

Jeff Canna 有关单元和功能测试的文章(developerWorks,2001 年 3 月)将 XP 哲学用在测试上。

关于作者

Roy W. Miller 是 RoleModel Software, Inc 的软件开拓职员。在 RoleModel 时代,Roy 开拓了基于 Java/XML 的自动验收测试框架,并为 Dallas Semiconductor 的 TINI Java 平台创建了几个利用的原型。在加盟 RoleModel 之前,他在 Andersen Consulting(现在是 Accenture)中办事了六年,用过他们的专用重量型商业集成措施 (MIB) 及其变体。自从加盟 RoleModel 后,他得到了许多有关 XP 以及对该措施的本地适应的履历。Roy 与他人合著了 Addison-Wesley XP 系列中的一本书(XP Applied,将于 2001 年 10 月出版),并是在 XP2001 "Business of XP" 展示会上的一名特邀专题评论争论小组成员。可以经由过程 rmiller@rolemodelsoft.com 与 Roy 联系。

Christopher T. Collins 是 RoleModel Software, Inc 的高档软件开拓职员。在 RoleModel 时代,Chris 介入了运行将近两年的一个 XP 项目,为新的摩托罗拉蜂窝式电话平台开拓了一个嵌入式 Java 利用法度榜样,并将 JUnit 移植到 Sun 的 J2ME 平台上运行。在加盟 RoleModel 之前,他花了 5 年的光阴应用许多不合的说话为一些组织开拓软件,近来的一次是为美国国防部开拓利用法度榜样。他拥有应用和适应涉及几种机动和重量型的不合开拓措施的履历,包括 RUP 和 XP。Chris 拥有美国西佛罗里达大年夜学谋略机科学和软件工程的硕士学位,今朝在北卡罗来纳州立大年夜学教授 Java 编程课程。他曾是杜克大年夜学有关 XP 的特邀演讲人,并将在 XP2001 上先容有关历程适应的论文。经由过程 ccollins@rolemodelsoft.com 与 Chris 联系。

您可能还会对下面的文章感兴趣: