使用 Java 语言所进行的面向对象编程变得空前普及它使软件开发发生了某种程度上的变革但最近的研究表明有半数的软件开发项目滞后而三分之一的项目则超出预算问题不在于技术而是开发软件所使用的方法所谓的轻量型或灵活方式与如Java这样的面向对象语言的威力和灵活性结合起来提供了一种很有意思的解决方案最常见的灵活方式称为极端编程（Extreme Programming）或者 XP但许多人并不真正了解它对 Java 项目使用 XP 可以大大增加成功的机会本文提供了XP的概述并解释了它为什么很重要——不是传言也没有骗局
在过去的十年中CEO们在产生稳步增加的收入方面面临巨大的压力他们通过在许多方面采取一系列举措来解决这一问题例如缩小公司规模外包再工程企业资源规划 (ERP) 等等这些对低效率的解决措施让 S&P 中的许多企业在 年代末能够连续几年保持两位数的收入增长但这种方式也带来了一些负面影响
在 Gary Hamel 所着的 Leading the Revolution（请参阅参考资料）一书中他声称已有一些迹象证明传统企业模式的优势已不那么明显我们必须找到一些替代方法来为收入的持续增长提供动力他建议唯一能让公司继续增长的办法是进行一次彻底的创新我们认为在软件开发领域中尤其需要这样
企业问题
如果使用标准软件开发方法那么即使在 Java 平台上进行开发也要做好失望的准备如图 所示最近的研究表明有一半项目将滞后而三分之一的项目将超过预算这一推测比 年由美国总审计局的研究结果好不了多少
图 软件项目成功和失败过去和现在
如果我们希望这些数字有显着提高则需要彻底创新的方法来开发软件有两个主要因素影响现有的方法
· 惧怕失败
· 对软件本质的误解
没有人打算失败具有讽刺意味的是为使失败最小化而创建的方法是失败的对软件的误解是问题的根源恐惧实际上只是一种症状现有的方法是由那些有良好愿望但忘记了软件中的软的那些聪明人所创建的他们假定开发软件就象造桥因此他们从各种设计规范中借鑒了一些适用于硬物体（例如桥梁）的最优方法结果是基于 Big Design Upfront (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 的十二种方法（如图 所示）将其定义为规则让我们仔细研究每一个方法来对执行 XP表示什么有个更全面的理解
图 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 小组都使用它们
