〈二〉XP 的十二种方法  

    XP 的十二种方法（如图 2 所示）将其定义为规则。让我们仔细研究每一个方法来对“执行 XP”表示什么有个更全面的理解。

图 2. XP 的十二种方法

    1）规划策略

    有些人会指责 XP 是一种美其名的剽窃，只是一群牛仔在没有任何规则的情况下将一个系统拼凑在一起。错。XP 是为数不多的几种承认您在开始时不可能事事通晓的方法之一。无论是用户还是开发人员都是随着项目的进展过程才逐步了解事物的。只有鼓励和信奉这种更改的方法才是有效方法。状态限定方法忽视更改。而 XP 则留心更改。它倾听所用的方法就是“规划策略”，一个由 Kent Beck 创造的概念。

    这一方法背后的主要思想是迅速地制定粗略计划，然后随着事物的不断清晰来逐步完善。规划策略的产物包括：一堆索引卡，每一张都包含一个客户素材，这些素材驱动项目的迭代；以及对下一两个发行版的粗略计划，如 Kent Beck 和 Martin Fowler 在他们的 Planning Extreme Programming 中描述的那样（请参阅参考资料）。让这种形式的计划得以发挥作用的关键因素是让用户做企业决策，让开发小组做技术决策。如果没有这一前提，整个过程就会土崩瓦解。

    开发小组要决定：估计开发一个素材要花多长时间 、使用各种技术选项所花费的成本 、团队组织 、每个素材的“风险” 、迭代中素材开发的顺序（先开发风险最大的那一个可以减轻风险）。

    客户需要决定： 范围（一个发行版的素材和每一次迭代的素材） 、发行日期 、优先级（根据企业价值先开发哪些特性）规划经常发生。这样，在客户或开发人员学习新事物的同时，就为他们调整计划提供了频繁机会。

    2）成对编程

    使用 XP，成对的开发人员编写所有产品代码。这种方式听上去好象缺乏效率。Martin Fowler 说，“当人们说成对编程降低生产力时，我回答，‘那是因为大多数耗费时间的编程部分是靠输入来完成的。’”实际上，成对编程无论在经济还是其它方面都提供了许多好处： 所有设计决策都牵涉到至少两个人、至少有两个人熟悉系统的每一部分、几乎不可能出现两个人同时疏忽测试或其它任务、改变各对的组合在可以在团队范围内传播知识、代码总是由至少一人复查。

    研究还显示成对的编程实际上比单独编程更有效（有关详细信息，请参阅参考资料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）。

    3）测试

    在 XP 中有两种测试： 单元测试 、验收测试 。

    开发人员在他们编写代码的同时编写单元测试。客户在他们定义了素材后编写验收测试。单元测试及时告诉开发人员系统在某一点上是否“工作”。验收测试告诉团队系统是否执行用户希望它执行的操作。

    假设团队使用的是如 Java 这样的面向对象语言，开发人员在为一些方法编写代码之前为每种有可能失败的方法编写单元测试。然后他们编写足够的代码使之能通过测试。有时人们会发现这有点奇怪。答案很简单。编写测试首先为您提供：一组可能最完整的测试 、可能能工作的最简单的代码 、代码意图的明确景象 。

    开发人员只有在通过所有单元测试后才可以将代码检入到源代码资源库中。单元测试使开发人员有信心相信他们的代码能够工作。这为其他开发人员留下线索，可以帮助他们理解最早的开发人员的意图（实际上，这是我们看到过的最好的文档）。单元测试还给了开发人员勇气重新划分代码，因为测试失败可以立刻告诉开发人员存在错误。应该将单元测试自动化，并提供明确的通过／失败结果。xUnit 框架（请参阅参考资料）做到的远不止这些，因此大多数 XP 小组都使用它们。

    用户负责确保每个素材都有验收测试来确认它们。用户可以自己编写测试、可以征募组织中的其他成员（例如 QA 人员或业务分析员）编写它们，也可以将这两种方法结合起来。测试告诉他们系统是否具有应该具有的那些特性，以及是否可以正确工作。理想情况下，用户在迭代完成之前就应该写好迭代中那些素材的验收测试了。应该将验收测试自动化，并要经常运行来确保开发人员在实现新特性时没有破坏任何现有的特性。通常情况下，客户需要来自开发团队的某些帮助来编写验收测试。我们对一个项目开发一个可重用的自动验收测试框架，可以让用户在简单编辑器中输入他们的输入和所期望的输出。框架将输入转换成 XML 文件、运行文件中的测试，然后为每个测试显示“通过”或“失败”。客户喜欢这一做法。

    不是所有验收测试都必须在所有情况下通过。问题是验收测试帮助客户衡量项目“完成”的情况如何。它们还可以让客户获悉有关某些事物是否可以发行的决定。

    4）重新划分

    重新划分是在不更改功能性的前提下对代码加以改进。XP 小组在进行重新划分时毫不手软。

    开发人员重新划分有两个重要时机：实现特性之前和之后。开发人员尝试确定更改现有代码是否可以让新特性的开发更容易。他们查看刚刚写好的代码，看是否有方法可以对它进行简化。例如，如果他们认为有抽象的机会，就会进行重新划分来从具体实现中除去重复的代码。

    XP 建议您应该编写可能运行的最简单的代码，但同时也建议您应该不断学习。重新划分让您将学到的知识加入到代码中，同时又不会破坏测试。它使您的代码简练。这意味着它可以存在相当长的时间、为以后的开发人员引入更少问题，并为他们指引正确的方向。

    5）简单的设计

    XP 的诽谤者说该过程忽略了设计。事实不是这样。问题是重量型方法建议您做的不过是提前完成大部分琐碎的设计任务。这就象是拍一张静态的地平线的照片，静止不动，然后尝试画一张如何到达那里的完美的地图。XP 说设计不应该在事物将保持不变的前提下预先仓促进行。XP 认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。

    什么是可能工作的最简单的设计？它是符合以下条件的设计（感谢 Kent Beck 为我们一一列出）： 运行所有测试 、不包含重复代码 、明确陈述程序员对所有代码的意图 、包含尽可能最少的类和方法 。

    对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。它们只不过需要尽可能简单，但是仍能工作。不要包括不使用的额外特性。我们称这样的事物为 YAGNI，表示“您将不需要它（You Aren't Going to Need It）。”不要让 YAGNI 破坏您成功的机会。