作为敏捷软件开发领域主流的开发方法，极限编程与其说是一种系统的方法学，倒更像是一系列最佳实践的有机结合。在这些最佳实践中，有些是已经广为人们所接受的（如编码标准），而更多的则极具颠覆性，初看之下让人似乎难以接受。

本文中，我将针对这些看似怪异的最佳实践阐述我的观点，并简述我对实施这些最佳实践的一些思考。

一、计划游戏

能够把计划叫做“游戏”是需要一定勇气的。在传统的软件开发方法学中，计划是举足轻重的一环，在制订计划前需要仔细的估算，在计划实施的过程中，还要不停的跟踪、修正，直至整个项目完成。

而在XP中，计划似乎要轻松许多。这并不是因为计划本身变得草率和无关痛痒，而是得益于XP的小版本发布思维。软件的一个版本是如此短小简单，以至于对它进行完整的评估、预算、跟踪和修正要容易许多。事实上，XP中采用的计划方式（业务人员和开发人员共同参与，各司其职）在大多数现代软件企业中早已采用，但是由于项目过于庞大，很难在开始阶段制订出完善的计划。而在XP中，人们只需要针对一个一两个月的小项目进行跟踪和管理，无形中降低了计划的风险。

二、隐喻

    在XP中，人们经常会使用隐喻来代替传统开发过程中的体系结构设计。从指导开发的角度来说，隐喻似乎不够精确，容易让人误解。但是，对于具有类似背景的同一个项目组中的开发人员来说，隐喻则更便于理解和交流。很难想象两个程序员面对着一张庞大的体系结构图时能够真正有效的沟通，而隐喻很好的解决了这个问题。

三、简单设计

不知道从什么时候开始，开发人员习惯了为明天而设计。一个开发人员设计了一个复杂的类继承结构，只是为了提高程序的所谓灵活性。没人知道这样值不值，并不是软件的每一个部分都需要扩展。但是，对于传统的软件开发人员来说，这么做又是迫不得已。如果没有预先做好准备，在变化来临时就会措手不及，付出沉重的代价。

但是在XP中，小版本发行的方法使得变化并不那么可怕，而重构的广泛采用，使得代码总是可以在需要时变得更加灵活。此外，由于你的代码总是会被别人审查（代码集体所有权和结对编程），因此也可以避免过于追求简单而忽视了重要的细节。

四、测试优先

没有代码要测试程序有什么用？这是测试优先最容易让人误解的地方。测试优先能够让开发人员更清楚的认识到，程序将会如何被使用。通过对不同的测试用例的思考，开发人员也能够更清晰的认识到程序的功能外延。而更多的其他的开发人员，则通过测试用例就可以获得一份精确的使用手册，在这份使用手册中，描述了作者考虑到的所有输入和输出结果，这样不仅便于人们了解程序，更增加了发现程序错误的机会（缺失的测试用例往往体现出作者忽视的某些使用情况）。

五、结对编程

两个程序员坐在一起，能够提高开发效率吗？程序员难道不是一群高傲的猫，习惯于离群索居，把头抬得高高吗？

事实并非如此。在一个正确的、合理的、能够实现的大目标下，程序员们不仅能够和平共处，更可以相互合作，创造出优秀的、高质量的程序。沟通一直是软件项目管理中的一个重要议题，而结对编程提供了一个十分有效的沟通渠道。此外，结对编程也更容易让新人融入团体。在几个高级程序员的指引下，他会更容易找出程序的脉络，把握程序的思想。较之正规的培训，这种方式更轻松也更有效。对于团队中的所有程序员来说，结对编程都是一个了解其他人设计思想的机会，通过结对编程，能够更好的实现代码集体所有权，也能够降低因为人员流动造成的风险。

结对编程最大的好处在于，能够极大的减少程序中潜在变化的可能性。两个人通过交流互相交换自己对程序的不同理解，更容易找出程序中可能出现的变化或错误，从而使程序更加可靠和健壮。

六、持续集成

集成一直是最费力的工作之一，本来工作的好好的代码，放在一起就不能运转，更糟糕的是成百上千条不知所云的错误码，没有人知道这些错误码来自何处。这是每个项目几乎都会遇到的最困难的阶段，程序员们必须集合在一起，翻阅数量巨大的接口定义文件，反复查看代码，同时还要不断的做出承诺。

持续集成正是解决上述问题的方法。通过多次、小增量的集成，我们总是能够以最快的速度定位错误出现的位置（因为增加的代码很少），结合大量测试用例，我们也可以确保每一个集成版本都尽可能的可靠。

此外，持续集成几乎可以在任何时间向我们提供一个可以工作的版本，我们可以将这个版本用于内部讨论和测试、客户展示、客户测试、小版本发布等等，这使得我们不需要花费太多的时间对现有的程序修修补补，以生成一个demo。

上文简单叙述了XP中常会引起争议的六个最佳实践的优点。下面本文将结合实际谈谈实施XP中需要注意的一些问题。

一、适用性问题

XP理论在提出时，明确的说明：XP是适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法。这就意味着，XP并不适用于所有情况。在准备实施XP前，你也许需要仔细评估项目的具体情况，以决定是否真的需要采用XP。

二、最佳实践间的关联

XP的一个特点是，它所推崇的最佳实践几乎总是和其它实践关联紧密，在实施一项最佳实践时，如果不同时实施其它实践，往往难以达到最初的目的。因此，在实施XP时，需要仔细研究各项实践间的关联，以确定最佳的实施方案。

三、宽松的环境

XP是一种追求自然的工作方法。它所倡导的是，程序员们以最自然开发的方式完成他们的工作。对于习惯了传统开发方法严格管理制度的管理人员来说，这往往是很难接受的。于是就出现了，虽然最高决策人决定实施XP，但管理层却无法（或不愿）给开发人员提供宽松的环境。在一个古板僵化的方框里，开发人员不会真正的回复自然，他们会装作正在实践XP，但事实上，他们依然在老路上行走（可以见到很多这样的例子，比如一些虚张声势的测试用例等等）。

四、忍受变化

XP对于传统软件项目管理思想的冲击，可能会使很多管理人员感到不舒服。也许XP一经实施，就会给项目组带来翻天覆地的变化。如果这样的变化让你感到恐惧，那么请暂时忍耐，你不能肯定这种变化不好，除非你亲眼看到。到那时再决定也不迟。

五、慢慢来

实施XP的过程不能操之过急。最好的方法是，在部分项目组中先行实施，实施时也不需要同时实施所有实践（但要注意各个实践间的关联问题）。有的时候你会发现，在实施了部分实践后，其它的实践也成为水到渠成的事情。当经过仔细评估，确信XP在项目组中确实有效后，再逐步在企业范围内推广，必要的时候，需要采取自愿的原则，由项目组的成员决定是否需要实施XP。

以上即是我在软件工程过程课程中以及平时工作、学习中对XP的一些认识。

来源： http://blog.csdn.net/leasun/archive/2006/08/15/1067508.aspx