4．XP

    下面是一个表格，包含了XP的12个要素，以及它们是怎样和敏捷原则关联的。

    XP概念（XP Concept）
 
    敏捷原则（Agile Principle）
 
       

    先看看右边的列，我们发现敏捷原则中的“交付价值”（#1）和“利用变化”（#2）没有关联到任何XP的原则，因为它们非常明确的作为动机被描述在XP中。“反省和调整（#12）也因为同样的原因没有被明确包含。

    有一些XP原则（XP#3：隐喻，XP#5：测试，XP#12：编码标准）没有在敏捷原则中找到对应的原则，还有一些，比如#7：结对编程，#8：集体所有制，则对应了多个原则。我们现在讨论那些XP概念中与上述12条敏捷原则相关的部分。

    XP#3：隐喻：一个系统的架构能够用隐喻来描述。系统的形状由在客户和开发者之间共享的隐喻来决定。这能够适用应用级别或者说软件架构级别。

    我们在实时系统和嵌入式系统中，可以看到三个主要的软件架构：监视和控制（Monitor and Control），传输机（Transporters），事务（Transactions）。更多的细节可以参考〔11〕。监视控制系统就是那些看起来象控制器的，PID控制回路等等。例子是电传飞行操作飞行器，铝、铁的旋转炉，居家温度控制，汽车控制系统，等等自动制动系统。

    传输系统就象一个电话系统，流数据毫无变化的通过它。 另外的例子是遥感测控，以及―有点令人惊讶的―离线信用卡处理，流数据通过系统，分别通向客户和商业银行，并定期总计金额。

    事务系统就象银行：它们维护一些抽象世界的图像，并且接受查询或者更新操作。很多工程系统，比如仿真系统就是遵循这个模式，制造业的系统也是这样。

    通过隐喻可以提供一个快速的相似物，通过说明这个系统象什么，来描述一个系统，这比直接去读详细的文档更有效。另外需要指出，一个隐喻也可以被写下来，本身成为“文档”。

    XP#5：测试：先设计和构造测试用例。这里的一个目标是保证高速度，易于构造和继承。如果测试用例都是马上可用的，而且不是在写代码之前，才能达到这个目标。另外一个目标是强迫去复查我们所做的东西是否符合需求。当我们写测试用例时，我们会更多考虑去符合需求，而不是代码。这样我们就可以得到更好的代码，因为我们已经考虑过了所有会走向错误的途径。

    这条原则也适用于构造可执行模型。可执行模型能够被校验者解释，或者被一个简单的 模型编译器编译。当我们完成分析，并开始建模，我们也必须定义一个可以测试的预先存在的实例，并定义场景（可能与用例的实例相反）。编码的时候，工作就趋向于专心确保我们得到的是正确的。

    XP#7:结对编程。成对的编程。这个概念就是指一个人编码时，另外一个人在反思以保证得到正确的代码。比起两个人各自单独编码，这条原则的确可以得到更高的生产力，因为失误以及错误的思路马上就被发现了，减少了浪费的时间。

    3－4个人的分析和建模团队是最有效率的。团队里应该有下列的一些角色：

    收集者：从领域专家、文档、背景源码（图书馆或者网络）收集信息。

    分析者：吸收这些信息并建立抽象。

    建模者：真正建造模型，登记模型，审核模型 等等。

    组织者：持续跟踪所有信息。

    无疑单独一个人也有能力担任所有的这些角色，但是关键是每个角色的要求是非常不同的。我们暂时回到结对开发，编码的人注意细节，这时另外一个人，他的手并不在键盘上，但是在发明，创造，和检查整个抽象产物，这是完全不同的行为。类似的，分析者在创建抽象的时候，用的是右半脑，而这时建模者在注意细节。参见《建模用的是右半脑》（Modeling on the Right Side of the Brain）, Starr [12]

    XP#8：集体所有。代码属于我们所有人。当我们在读一些不是我们自己写的代码，而且我们找到了一个问题，把“别人的东西”改正确是可怕的。集体所有为了拒绝这个问题，通过鼓励知识传播，以及不鼓励私下里的实践。

    同样的思想可以不用修改地应用于建模。想这么做，要保证把所有的信息和模型放到一个仓库（知识库）中。这样节省了庞大的寻找信息的时间，减少了信息传递路径的数量。

    XP#12：编码标准。哦，是的，建模也是如此。注意这和#11，集体所有，是相对应的。