【作者】:
Willy Farrell （
[email protected]），电子商务体系架构设计师，IBM
Mary-Rose Fisher （
[email protected]），电子商务体系架构设计师，IBM
2001 年 6 月
在本文中 Willy Farrell 和 Mary-Rose Fisher 讨论了开发者引入软件项目的四点价值：沟通、简单、反馈和勇气。极端编程是一套应用这些有价值的东西来创造一个环境的惯例，在这个环境中，您可以快速而正确地开发商业应用。同时还讨论了极端编程的 12 个基本惯例。
“听取意见、测试、编码、设计。这就是开发软件要做的全部工作。任何告诉您不是这样的人都是想推销什么东西。”— Kent Beck，极端编程的作者。
沟通，或更准确地说，缺乏沟通，是几乎所有软件问题的根源。客户没与开发者沟通他的要求，或开发者没与客户沟通提供一个功能的困难之处。如果涉及的各方直接，及时地互相沟通，就可以消除大多数问题。我们不能忽视或惩罚任何诚实的沟通。
简单。有什么最简单的事情可能会起作用？我们的注意力太多放在了软件的最复杂难解的功能上，而这些功能我们很少用到或者只是曾经用过。今天做简单的工作，明天花点代价修改它要比今天做可能永远用不到的复杂工作好的多。这也和我们的沟通价值紧密联系在一起，因为系统越简单，需要的沟通越少。
反馈告诉我们工作做得怎么样，以及以后要如何做。我们需要对正在运行的系统的反馈，以便了解它是否满足了客户的要求。我们需要通过反馈来了解系统将需要哪些最有价值的改进、加强和附加。我们还需要通过反馈来了解，我们什么时候能够交付某个特定的功能。如果不知道以前的速度又如何确定将来的速度？
我们还把勇气带进了软件开发中。我们有没有勇气尝试新的、不同的东西来大幅减少项目时间？我们有没有足够的勇气在即使面对巨额预算和截止期限压力时仍能坚持做正确的事情？
你有勇气吗？是否已厌倦了过度复杂且缺少真正有创意的项目？有没有做好准备去谈判，而不是让别人指定预算和时间限制？想真正了解用户的需要和愿望吗？那么来吧 — 开始使用极端编程吧！
极端编程说明
极端编程（XP）是一套用于软件开发的惯例，它应用上述的几点价值来创建一个环境，该环境有助于快速、准确地开发商业应用。如果您编过一段时间程序，可能在看到下面的惯例时会想：“这些也不新鲜；我以前已经做过其中一些了。”您是对的。
XP的革新只是把所有的惯例放在一起，以便它们互相支持。一些惯例的优势会弥补其它惯例的缺点。
您可能会突然想起非正式的 XP 看起来应该是什么样的。但不要被愚弄了 — 虽然它是非正式的，但同样要求许多纪律。您不得不遵守这些 XP 惯例，这里指的是所有的 XP 惯例，要不您就不是在进行极端编程。
XP 的 12 条惯例
#规划游戏
#小型发行版
#共享智力模型的隐喻
#测试
#正确的设计
#重组
#成对编程
#集体所有权
#连续的集成
#每周 40 小时工作制
#现场客户
#编码练习
基本原则
在讨论这些惯例之前，这里还有一些基于上面的四点价值的 XP 基本原则。
#快速反馈
行动和对该行动的反馈之间的时间是至关重要的。您需要马上知道事情是好是坏。
#假设简单
它可以节约时间。对待每一个问题都好象可以绝对非常简单地解决。几乎任何时候，都可以这样简单地解决。您节约了要在实际需要复杂解决方案的问题上花费的时间。
#递增更改
大的更改是不起什么作用的。即使在最小的商业应用中也有太多的关系和互相依赖，使我们想象得到对体系结构或代码的大规模更改肯定会产生问题。但随着时间的推移，进行一系列的使得所开发的商业应用有所不同的最小型更改，最终会形成大规模的更改。
#信奉更改和高质量工作
有人说，这个世界上没有一成不变的东西。我们必须接受，甚至信奉更改。但不是要预计可能发生的每个可能的改变，如果在解决我们的大多数紧迫的问题时能够制定出保留选择余地的策略，这样会有效的多。
至于高质量工作，有两种选择：优秀和极端优秀。不要做比这差的工作。与我们同事的所有优秀程序员都有干出优秀的、高质量的工作的信仰。
听取意见、测试、编码、设计 — 按照这个顺序
现在让我们围绕已经讨论过的价值和原则构建我们的开发活动。我们要执行的最重要的活动有：
#听取意见
#测试
#编码和设计
按照这个精确的步骤执行。为什么要按照这样的步骤？在后面我们会稍加说明。
只是简单地互相听一下意见是不起什么作用的。我们必须真正用心去听，只交流那些确实需要交流的内容，而不是我们惯常谈论的那些与主题无关的无价值的东西。
制定一些规则以确保鼓励交流真正值得交流的东西，而阻止交流无关的内容。交流无关的内容只是浪费时间。
使所有的测试自动化。如果无法测量的话，自动测试不会存在。自动测试会增强我们对系统的信心，并使我们自信有能力进行提高质量的更改。我们需要两种类型的测试以适应两种用户：单元测试（针对程序员）和验收（或功能）测试（针对客户）。
开发工作绝对无法缺少的一种人工制品是我们写出的真实的、全能的代码。我们的代码表达了目的、算法和结构。代码要写得清楚而明了。
如果代码最终是可交付使用的，那么设计就至关重要。我们必须创建一个结构将系统中的逻辑组织起来。只是因为一个部分中的逻辑要求修改时不能必然意味着另一个部分中的逻辑也跟着要求修改。将逻辑放在数据（逻辑在该数据上操作）的旁边允许只在一处更改的系统扩展。设计必须要有上下文，在上下文中可创建好的设计，修改不好的设计，而且与项目有关的每个人都能理解标签。
现在，感觉这个奇怪的顺序怎么样？在 XP 中，开发是象这样进行的：我们听取需要做什么。然后，编写测试，如果通过了，则证明我们交付了需要做的东西。下一步，我们编写将通过那些测试的代码。最后，我们调整代码的设计使其更简单、更有效，同时仍能够通过测试。
听起来很荒谬，是吧？这就是极端编程！
基本 XP 惯例
角色分工在惯例中具体表达为规划游戏。根据技术考虑因素平衡业务考虑因素。适当地规划。记住，业务人员负责业务决定。那些决定包括范围、产品功能的优先级、发行版的组成以及发行日期。技术人员负责关于项目的技术决定。他们估计时间框架和功能之间的因果关系。它们还定义开发过程和详细的进度表。就象一个真实的游戏一样，在创建一个有用的软件的过程中，规划游戏具有指导每个业务方面和技术方面的目标和规则。
如果考虑到小型发行版形式的话，极端编程将是最成熟的。它使人们可真正获得发行版。不是一年一次或一年二次，而是不超过一个月或两个月一次，通过调整或改变每个发行周期提高掌握项目的机会。但是，记住，每个发行版应作为整体才有意义。只为缩短发行周期，而发行一个功能的一半是不可接受的供选方法。
在项目开发中，沟通是关键因素。在 XP 中创建了业务人员和技术人员之间的共享智力模型，它定义了简单的系统工作机制。它变成了关于系统的讨论的隐喻。由于对根本目标的描述有强烈的一致意见，这个项目向成功迈开了一大步。
还记得有些人在写代码并将代码交给二流的测试组织时是多么傲慢吗？那些日子已成往事！我们编写自己的测试代码并且必须在编写代码本身之前，把它们写出来。所有的单元测试必须 100% 运行。验收测试对于每个功能都应该是自动的，这样我们就可以知道发行版迭代何时完成。考虑每一种可能使一段代码崩溃的方式，并写一个测试案例来测试它。信不信由你，这种主动的测试在改善和证明代码的同时实际上还会加快开发速度。
为今天设计。保持简单。正确的设计不会有重复的逻辑并且声明每个对程序员来说重要的意图。它运行所有的测试案例且拥有的类和方法可能最少。我们太习惯于为明天设计。使用XP，您可以在需要的时候提出自己所需要的。对于所有的项目，随着新功能和新发行版的出现，设计都要随时间的推移发生更改。为今天设计是因为下一个惯例将为后来的更改提供方法。
通过更改代码来更改系统设计是可行的。重组就是通过更改现有的代码来简单地添加附加的功能。但它不是一种添加代码的投机方法，因为它可能是一种好的想法。除去重复的代码，改进代码结构、或加强设计都会是进行更改的好基础。
有人不是说过三个臭皮匠顶个诸葛亮吗？XP 最具争议的概念是成对编程思想。这种概念是所有的产品代码都是由两个人看着同一台机器，只用一个键盘和一个鼠标写的。这是管理者的生产恶梦！但成对编程的确很有用。一个人考虑如何用最好的方式实现一个方法而另一个人从战略角度考虑：这种方法行得通吗？其它还有什么测试案例？我们如何简化代码？
如果两个人变得对输出负责，那么集体所有权当然会变成标准。任何程序员，如果看到有为代码的任何部分增加价值，都能够 — 不，是被强迫、被要求 — 为代码增加价值。每个程序员都对整个系统负责。并非每个人对每一部分都一样理解得很好，但每个人对每一部分都有一定的了解。我们实现了集体加个人的思想！
由于每个人都参与，每几个小时或至少每天都要执行一次连续的集成和测试。目前正在集成他们最近的代码变化的那两个人变成了显然要负责修正失败的测试的一批人。测试必须百分之百运行 — 成功率没有减少的余地。
但虽然所有的测试都必须运行，高效率的规划仍集中在每周 40 小时工作制上。工作人员必须是精神饱满且富有创意的、仔细且自信的。连续许多周每周工作 60个小时会导致粗心和错误。持续加班可能是严重问题的征兆。某一周有时加加班是可以的。但是，当第二个紧张的加班周开始时，就要找潜在的问题。
极端编程还使用了另一个新颖的思想 — 现场客户。以前客户会很快清楚地说出自己的要求，可现在现场客户变成了实现小组的一员。这个小组成员变成了响应问题、解决争端和设置小规模优先级的无价之宝。但现场客户必须是真实的。他们必须是理解整个系统的人和有可能实际使用这个系统的候选人。
如果所有的开发者都能够随时更改系统的任何部分，我们就供不起不同的编码练习了。谁或哪个小组写了什么代码这种说法就变得不可能了。程序员醒悟了！XP意味着在代码格式化上您要与多数人保持一致。
这就是 XP。您会问，这怎么有用呢？想一下惯例是如何互补的。其中一个的弱点被另一个的优势弥补。如果每个人都使用 XP 惯例，那么惯例之间的交互会提供平衡。记住，12 个惯例必须全部执行。
实现策略
有几个策略可用于实现 XP 方法学。但，管理者负责全部决定和每个人想做什么就做什么这两种策略都是注定要有的。在应用 XP 原则时，我们相信管理者应该重点强调需要完成的工作，而不分配工作。一种策略是假设程序员希望为小组工作做出的贡献超过个人目标，而另一种策略是程序员希望小组做伟大的工作，达到成功。
极端编程的管理策略意味着将 XP 应用于本地条件，并帮助解决公司间的文化差异。我们还将轻装上阵，开销也极少。长时间的会议和冗长的状态报告消失了。测量是诚实的。在精确度比较现实的级别上将度量制聚集在一起，而不计算每一秒或每一分钟。这是一个人优先于过程的环境。我们不是插上就兼容的编程单元。
规划策略把小组成员聚集在一起决定范围和优先级，并估计成本和时间进度。结果会制定出一个计划，每个人都有信心能够，也应该执行这个计划，开发出所需的系统。该规划还提供反馈的标准。但规划并不是到此为止。规划是在系统的较低级别上实施，它是连续的，并持续参考最新的反馈。
开发、测试和设计策略杂乱无章地与惯例（每个惯例与一个过程相关）联系在一起。对于开发，有连续的集成、成对编程以及集体所有权。对于测试，有单元测试和验收测试。而设计则依赖于“最简单的东西可能会起作用”以及贯穿实现的代码的抽象思想的具体反馈。
简单但困难
极端编程简单但困难。为什么？因为，哦，做简单的事情很难。就象这句话听起来一样奇怪，我们已经习惯于为明天设计，并且佩服那些能够让复杂的东西起作用的人。承认自己不懂什么东西也很困难，而且极端编程是基于这样一种前提 —您开发的速度只赶得上学习的速度。最后，合作很困难；因为小时侯我们就习惯于根据个人成就取得酬劳。尽管存在上述这些障碍，极端编程还是可行的。
我们希望这些对极端编程的价值、原则、惯例的介绍会对您有所帮助。极端编程这种思想已经激起了我们的兴趣，我们的组织立即决定在名为 GoForIt 的项目中使用这个概念。在后面的几个月，我们小组的成员将合作共享我们学到的 XP 方面的经验和教训。通过阅读这些文章，我们希望您会经历一场使用极端编程进行的真实的项目实现。
【参考资料】:
参阅本文的讨论论坛。
阅读编码冒险开始来熟悉 Go-ForIt 工程。
相关的 developerWorks 文章包括：
XP distilled
Does anyone really XP?
您可以参考下面这些书籍学习更多关于极端编程的知识：
eXtreme Programming Explained: Embrace Change ，Kent Beck 著
（Addison Wesley Longman 公司出版，1999 年）
Extreme Programming Installed，Ron Jeffries、Ann Anderson 和 Chet
Hendrickson 著（Addison Wesley Longman 公司出版，2000 年）
Planning Extreme Programming ，Kent Beck 和 Martin Fowler 著
（Addison Wesley Longman 公司出版，2000 年）
Refactoring: Improving the Design of Existing Code ，Martin Fowler著
（Addison Wesley Longman 公司出版，2000 年）
下列 Web 站点也很有用：
xProgramming.com 是一个社区资源，提供关于 XP 和相关主题的信息。
极端编程提供 XP 的介绍和概述。
重温这个讨论组（在 Yahoo! 上），提供有关 XP 实践和原则的信息。
请从 wiki wiki 入口开始学习 XP。
更多开发者解决方案参考资料
【关于作者】:
Willy Farrell 是位于美国德克萨斯州，奥斯汀的 IBM Developer Relations
Technical Consulting 的首席电子商务体系架构设计师，该公司为 IBM 商业伙伴提供教育、实现和咨询。他从 1980 起就以从事计算机编程为生，从 1996 开始使用 Java，并于 1998 年加入 IBM。Willy持有下列技术证书（另外还有其它证书）：
Java Programmer、VisualAge for Java Solution Developer、MQSeries Solutions
Expert、WebSphere Application Server Solution Developer、XML Developer 和
IBM e-business Solution Technologist。您可通过
[email protected]
与他联系。
Mary-Rose Fisher 从 20 世纪 90 年代中期开始投身于 Taligent 和 OpenDoc的对象技术。随着 Java 语言的发展，她成了向 RS/6000 和 AIX 做移植的 IBM ISV电子商务开发者的核心人物。目前她是 Developer Relations 部门的电子商务体系架构设计师。您可通过
[email protected] 与她联系。