3.5 成对编程

    使用 XP，成对的开发人员编写所有产品代码。这种方式听上去好象缺乏效率。Martin Fowler 说，*当人们说成对编程降低生产力时，我回答，'那是因为大多数耗费时间的编程部分是靠输入来完成的。'*实际上，成对编程无论在经济还是其它方面都提供了许多好处：

    所有设计决策都牵涉到至少两个人。

    至少有两个人熟悉系统的每一部分。

    几乎不可能出现两个人同时疏忽测试或其它任务。

    改变各对的组合在可以在团队范围内传播知识。

    代码总是由至少一人复查。
   
    研究还显示成对的编程实际上比单独编程更有效。

    3.6 小发行版

    发行版应该尽可能地小，同时仍然提供足够的企业价值以证明它们值得。
 
    只要觉得有意义就可以发布系统。这样就尽可能早为用户提供了价值（请记住，今天的钱比明天的钱来得值钱）。小发行版将为开发人员提供具体的反馈意见，告诉他们哪些符合客户需要，哪些不符合客户需要。然后，小组可以将这些经验教训包括在其下一发行版的规划中。

    3.7 简单的设计

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

    什么是可能工作的最简单的设计？它是符合以下条件的设计：

    运行所有测试

    不包含重复代码

    明确陈述程序员对所有代码的意图

    包含尽可能最少的类和方法

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

    3.8 集体代码所有权 
    
    小组中的任何人都应该有权对代码进行更改来改进它。每个人都拥有全部代码，这意味着每个人都对它负责。这种技术可以让人们对部分代码进行必要的更改而不用经过代码拥有者个人的瓶颈。每个人都负责这一事实消除了无代码所有权所带来的混乱。

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

    3.9 持续的集成

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

    传统方法工作方式如下：编写大量代码后执行一次大爆炸式的集成，然后花费相当长的时间来改正问题。这种笨拙的形式的确使项目速度减缓。大爆炸式的集成给团队立即带来大量问题，并且这些问题通常都有几百种可能的原因。

    如果经常进行集成，任何特定集成失败的原因都会非常明显（以前运行过测试，因此错误一定是新事物犯下的）。使用这种方法，当遇到问题时，可能的原因就相当有限。修改起来更容易，花的时间少得多，使团队保持最快速度前进。

    3.10 现场客户

    要使功能最理想，XP 小组需要在现场有一位客户来明确素材，并做出重要的企业决策。开发人员是不允许单独做这些事情的。让客户随时在场可以消除开发人员等待决策时出现的瓶颈。

    XP 不会假装素材卡是开发人员交付必要代码所需的唯一指示。素材是对以后在客户和开发人员之间填写细节的对话的一项承诺。与将所有要求写在一个静态文档中不同，其思想是进行面对面的交流，减少产生误解的机会。

    我们发现让客户在现场是可能最好的一种情形，但这不是解决问题的唯一方案。底线是客户必须随时在需要回答问题和根据企业价值为团队提供指示时有空。如果客户并非在现场专职陪伴团队的情况下就能做到这些，那很好。如果能和团队待在一起，这会更方便，但只是建议而已。