XP 核心的实践

极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。

1、小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

2、规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。

3、现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。

4、隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。

5、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。

6、重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

7、测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。

8、持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

9、结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

10、代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。

11、编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。

12、每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。

在第二版的Extreme programming explained中，在主要实践之外，还列出了一系列延伸的实践。

核心实践源自被广泛接受的最佳实践，并且被推向极至：

开发人员和客户之间的交互是有益的。因此，一个极限编程的小组从理论上要求需要一个软件使用者在身边，这个使用者制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）.

如果学习是好的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。

简单的代码更可能工作。所以极限编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。

如果简单的代码是好的，那么把变得复杂的代码改写成简单的。

代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。

测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先变好的自动化测试方式来保证它的确有作用。参看 测试驱动的开发。

一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为统一软件程序更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。