7.测试驱动 ( Test-driven )

• XP： 强调"测试先行"。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。
• 评述： RUP与XP对测试都是非常的重视，只是两者对于测试在整个项目开发周期内首先出现的位置处理不同。XP是一项测试驱动的软件开发过程，它认为测试先行使得开发人员对自己的代码有足够的信心，同时也有勇气进行代码重构。测试应该实现一定的自动化，同时能够清晰的给出测试成功或者失败的结果。在这方面，xUnit测试框架做了很多的工作，因此很多实施XP的团队，都采用它们进行测试工作。
• 项目： 我们在项目初期就对JUNIT进行了一定的研究工作，在项目编码中，采用JBUILDER6提供的测试框架进行测试类的编写。但是，不是对所有的方法与用例都编写，而只是针对关键方法类、重要业务逻辑处理类等进行。详细的关于JUNIT测试框架的使用，请参见我的同事撰写的另一篇文章(http://www-900.ibm.com/developerWorks/cn/java/l-junit/index.shtml)

    8. 代码重构 ( Refactoring )

• XP： 强调代码重构在其中的作用，认为开发人员应该经常进行重构，通常有两个关键点应该进行重构：对于一个功能实现和实现后。
• 评述： 代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。
  在使用代码重构的时候要注意，不要过分的依赖重构，甚至轻视设计，否则，对于大中型的系统而言，将设计推迟或者干脆不作设计，会造成一场灾难。
• 项目： 我们在项目中将JREFACTORY工具部署到JBuilder中进行代码的重构，重构的时间是在各个迭代周期的前后。代码重构在项目中的作用是改善既有设计，而不是代替设计。

    9. 成对编程 ( Pair Programming )

• XP： 认为在项目中采用成对编程比独自编程更加有效。成对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。
• 评述： 其实，成对编程是一种非正式的同级评审 ( Peer Review )。它要求成对编程的两个开发人员在性格和技能上应该相互匹配，目前在国内还不是十分适合推广。成对编程只是加强开发人员沟通与评审的一种方式，而非唯一的方式。具体的方式可以结合项目的情况进行。
• 项目： 我们在项目中并没有采用成对编程的实践，而是在项目实施的各个阶段，加强了走查以及同级评审的力度。需求获取、设计与分析都有多人参与，在成果提交后，交叉进行走查；而在编码阶段，开发人员之间也要在每个迭代周期后进行同时评审。

    10.

• XP： 认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。
• 评论： 代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG的修复。
  在目前，国内的软件开发组织，可以在一定程度上实施该实践，但是同时需要注意一定要有严格的代码控制管理。
• 项目： 我们在项目开发初期，首先向开发团队进行"代码全体拥有"的教育，同时要求开发人员不仅要了解系统的架构、自己的代码，同时也要了解其它开发人员的工作以及代码情况。这个实践与同级评审有一定的互补作用，从而保证人员的变动不会对项目的进度造成很大的影响。
  在项目执行中，有一个开发人员由于参加培训，缺席项目执行一周，由于实行了"代码全体拥有"的实践，其它的开发人员成功地分担了该成员的测试与开发任务，从而保证项目的如期交付。

    11. 持续集成 ( Continuous Integration )

• XP： 提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。
• 评述： 持续集成也不是XP专有的非常好的实践，著名的微软公司就有每日集成 ( Daily Build ) 的成功实践。但是，要注意的是，持续集成也需要良好的软件配置变更管理系统的有效支持。
• 项目： 使用VSS作为软件配置管理系统，坚持每天进行一次的系统集成，将已经完成的功能有效地结合起来，进行测试。

    12. 小型发布 ( Small Release )

• XP： 强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
• 评论： 小型发布突出体现了敏捷方法的优点。RUP强调迭代式的开发，对于系统的发布并没有作出过多的规定。用户在提交需求后，只有在部署时才能看到真正的系统，这样就不利于迅速获得用户的反馈。
  如果能够保证测试先行、代码重构、持续集成等非常好的实践，实现小型发布也不是一件困难的事情，在有条件的组织可以考虑使用。
• 项目： 项目在筹备阶段就配置了一台测试与发布服务器，在项目实施过程中，平均每两周（一个迭代周期结束后）进行一个小型发布；用户在发布后两个工作日内，向项目小组提交"用户接收测试报告"，由项目经理评估测试报告，将有效的BUG提交至Rational Clear Case，并分配给相应的开发人员。项目小组应该在下一个迭代周期结束前修复所有用户提交的问题。

    以上是XP的非常好的实践在项目中的应用情况，让我们查看以下该项目的详细统计数据：

    其中，项目执行过程中提交了一个"用户需求变更"，该变更对于项目周期的影响为6个工作日。
    项目实施后，在用户接收测试中，只提交了2个BUG，而且在提交当天就得到了解决。目前，项目运行平稳，并得到了用户的好评。因此，我们认为，XP在该项目中的实施有效地保证了项目质量和项目周期。