XP 精华 如何使 java 项目获得更大成功 Roy W. Miller (rmiller@rolemodelsoft.com) 软件开发人员，RoleModel Software, Inc. Christopher T. Collins (ccollins@rolemodelsoft.com) 高级软件开发人员，RoleModel Software, Inc.
内容：
企业问题 一种解决方案：灵活方法 XP 的 12 种方法 一起工作的方法 为什么 XP 很重要 参考资料 关于作者 评价这篇文章
使用 Java 语言所进行的面向对象编程变得空前普及。它使软件开发发生了某种程度上的变革，但最近的研究表明，有半数的软件开发项目滞后，而三分之一的项目则超出预算。问题不在于技术，而是开发软件所使用的方法。所谓的“轻量型”或“灵活”方式，与如 Java 这样的面向对象语言的威力和灵活性结合起来，提供了一种很有意思的解决方案。最常见的灵活方式称为极端编程（Extreme PRogramming）或者 XP，但许多人并不真正了解它。对 Java 项目使用 XP 可以大大增加成功的机会。本文提供了 XP 的概述，并解释了它为什么很重要 -- 不是传言，也没有骗局。
在 Gary Hamel 所著的 Leading the Revolution（请参阅参考资料）一书中，他声称已有一些迹象证实传统企业模式的优势已不那么明显。我们必须找到一些替代方法来为收入的持续增长提供动力。他建议唯一能让公司继续增长的办法是进行一次彻底的创新。我们认为在软件开发领域中尤其需要这样。
XP 提供了十年来最大的一次机会，给软件开发过程带来彻底变革。就象 Peopleware 作家 Tom DeMarco 所说，“XP 是当今我们所处领域中最重要的一项运动。预计它对于目前一代的重要性就象 SEI 及其能力成熟度模型对上一代的重要性一样。”
XP 规定了一组核心价值和方法，可以让软件开发人员发挥他们的专长：编写代码。XP 消除了大多数重量型过程的不必要产物，通过减慢开发速度、耗费开发人员的精力（例如干特图、状态报告，以及多卷需求文档）从目标偏离。我们熟悉到一个称为“极端编程”的东西可能很难作为正式的开发过程推荐给治理层，但假如您的公司从事软件行业，您应该帮助治理层绕过其名称熟悉到 XP 可以提供的竞争优势。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一书中概括了 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 中描述的那样（请参阅参考资料）。让这种形式的计划得以发挥作用的要害因素是让用户做企业决策，让开发小组做技术决策。假如没有这一前提，整个过程就会土崩瓦解。
开发人员只有在通过所有单元测试后才可以将代码检入到源代码资源库中。单元测试使开发人员有信心相信他们的代码能够工作。这为其他开发人员留下线索，可以帮助他们理解最早的开发人员的意图（实际上，这是我们看到过的最好的文档）。单元测试还给了开发人员勇气重新划分代码，因为测试失败可以马上告诉开发人员存在错误。应该将单元测试自动化，并提供明确的通过／失败结果。xUnit 框架（请参阅参考资料）做到的远不止这些，因此大多数 XP 小组都使用它们。
用户负责确保每个素材都有验收测试来确认它们。用户可以自己编写测试、可以征募组织中的其他成员（例如 QA 人员或业务分析员）编写它们，也可以将这两种方法结合起来。测试告诉他们系统是否具有应该具有的那些特性，以及是否可以正确工作。理想情况下，用户在迭代完成之前就应该写好迭代中那些素材的验收测试了。应该将验收测试自动化，并要经常运行来确保开发人员在实现新特性时没有破坏任何现有的特性。通常情况下，客户需要来自开发团队的某些帮助来编写验收测试。我们对一个项目开发一个可重用的自动验收测试框架，可以让用户在简单编辑器中输入他们的输入和所期望的输出。框架将输入转换成 xml 文件、运行文件中的测试，然后为每个测试显示“通过”或“失败”。客户喜欢这一做法。
XP 建议您应该编写可能运行的最简单的代码，但同时也建议您应该不断学习。重新划分让您将学到的知识加入到代码中，同时又不会破坏测试。它使您的代码简练。这意味着它可以存在相当长的时间、为以后的开发人员引入更少问题，并为他们指引正确的方向。
简单的设计 XP 的诽谤者说该过程忽略了设计。事实不是这样。问题是重量型方法建议您做的不过是提前完成大部分琐碎的设计任务。这就象是拍一张静态的地平线的照片，静止不动，然后尝试画一张如何到达那里的完美的地图。XP 说设计不应该在事物将保持不变的前提下预先仓促进行。XP 认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。
什么是可能工作的最简单的设计？它是符合以下条件的设计（感谢 Kent Beck 为我们一一列出）：
运行所有测试 不包含重复代码 明确陈述程序员对所有代码的意图 包含尽可能最少的类和方法
对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。它们只不过需要尽可能简单，但是仍能工作。不要包括不使用的额外特性。我们称这样的事物为 YAGNI，表示“您将不需要它（You Aren′t Going to Need It）。”不要让 YAGNI 破坏您成功的机会。
“每人拥有所有代码”与“没人拥有代码”的说法并不一样。没人拥有代码时，人们可以随处进行破坏而不必负任何责任。而 XP 说，“假如是您破坏的，应该您来弥补。”我们有一些必须在每次集成之前和之后运行的单元测试。假如您破坏了某些事物，您要负责进行修补，无论它位于代码的哪一部分。这需要极端规则。可能这是名称中带有“极端”的另一个原因。
