一、什么是极限编程？
XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
与其他方法论相比，其最大的不同在于：
- 在更短的周期内，更早地提供具体、持续的反馈信息。
- 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
- 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
- 依赖于口头交流、测试和源程序进行沟通。
- 倡导持续的演化式设计。
- 依赖于开发团队内部的紧密协作。
- 尽可能达到程序员短期利益和项目长期利益的平衡。
XP 由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并通过行为贯穿于整个生命期。
二、价值观
沟通（Communication）：XP 方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性。因此，XP 组合了诸如对编程这样的最佳实践，鼓励大家进行口头交流，通过交流解决问题，提高效率。
简单（Simplicity）：XP 方法论提倡在工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。这一点看上去十分容易，但是要真正做到保持简单的工作其实很难的。因为在传统的开发方法中，都要求大家对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展的空间。
反馈（Feedback）：通过持续、明确的反馈来暴露软件状态的问题。具体而言就是：1、在开发团队内部，通过提前编写单元测试代码，时时反馈代码的问题与进展。2、在开发过程中，还应该加强集成工作，做到持续集成，使得每一次增量都是一个可执行的工作版本，也就是逐渐是软件长大，整个过程中，应该通过向客户和管理层演示这些可运行的版本，以便及早地反馈，及早地发现问题。
勇气（Courage）：在应用 XP 方法论时，由于沟通良好，因此会有更多需求变更的机会；由于时刻保持系统的简单，因此新的变化会带来一些重新开发的需要；由于反馈及时，因此会有更多中间打断你的思路的新需求；处于变化之中，因此这时就需要有勇气来面对快速开发，面对可能的重新开发。XP 方法论让问题早出现、早解决，是实现“小步快走”开发节奏的好办法。
三、五个原则
快速反馈：及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。这也是对反馈这一价值观的进一步补充。
简单性假设：类似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。
逐步修改：不要一次做出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理同样适用，任何问题都应该通过一系列能够带来差异的微小改动来解决。
提倡更改：在软件开发过程中，最好的办法是在解决最重要问题时，保留最多选项的那个。也就是说，尽量为下一次修改做好准备。
优质工作：在实践中，经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，由于不影响使用就先不管；某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象，这样的坏习惯一旦养成，必然使得代码质量大打折扣。在 XP 方法论中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。
四、十三个最佳实践
计划游戏（planning Game）：计划游戏可以视为用例的较小版本。这样，客户可以尽可能简短地定义新应用程序的规范（功能、价值、优先级），这些故事将成为项目团队进行项目成本估算和管理的基础。
小型发行版（Buidling Block）：由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。
隐喻（System Metaphor）：开发人员和程序员必须遵守名称，类名和方法的标准。
简单的设计 (Simple Design)：始终寻找尽可能简单的系统实现但又满足所有必需功能的系统实现。
测试 (Testing)：每个小的发行版（称为构建块）都必须通过测试，然后才能发行。XP在这方面的独特之处在于测试首先创建，然后应用程序代码的开发，最小程度的避免Bug产生。
重构 (Refactoring)：所有团队成员应不断调整和改进应用程序。这要求成员之间进行非常良好的沟通，以避免重复工作。重构技术是对简单性设计的一个良好的补充。
结对编程 (Pair Programming)： XP程序员可以成对工作。所有代码都是由在同一台计算机上一起工作的两个程序员开发的。结对编程以相同或更少的成本生成更高质量的代码，主要是结对编程大打降低了沟通的成本，提供了工作的质量。结对编程技术被誉为 XP 保持工作质量、强调人文主义的一个典型的实践，应用得当还能够使得开发团队之前的协作更加流畅、知识交流与共享更加频繁，团队的稳定性也会更加稳固。
集体所有制 (collective Ownership)：在XP方法论中，所有代码均被视为由整个团队拥有，而不是单个财产。因此，所有代码都将由所有人审查和更新，每个人都拥有全部代码，也都需要对全部代码负责。
持续集成 (Continuous Integration)：持续集成的含义则是要求 XP 团队每天尽可能多次地做代码集成，每次都在确保系统运行的单元测试通过之后进行。可以及早地暴露、消除由于重构、集体代码所有制所引入的错误，从而减少解决问题的痛苦。
每周工作40个小时 (40-hour workweek)：精力不足的时候，不仅写出来的代码质量没有保障，而且还可能为项目带来退步的效果。拒绝加班～
现场客户 (On-site customer)：在 XP 项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于 XP 项目而言有着十分重要的意义。此处是后置验证环节，是否符合客户预期。
编码标准 (Coding standard)：编码的样式和格式必须相同，以确保团队成员之间的兼容性。这种方法可以加快协作速度。XP 方法论认为拥有编码标准可以避免团队在一些与开发进度无关的细节问题上发生争论，而且会给重构、结对编程带来很大麻烦。
配合是关键：以上少一个都不行，配合使用，法力无边！
