XP 极限编程

      极限编程 （Extreme Programming ， X P）是一门针对业务和软件开发 的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件 为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求 变化，哪怕是在软件生命周期 的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构 不如直接编程来的直接。

      XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National Bank　Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。

　　同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。

　　XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。

　　XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
 
　　XP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。

一、XP的核心思想

      从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

二、XP的十二种方法

      规划策略(The Planning Game)；
      结对编程(Pair programming)
      测试(Testing)
      重构(Refractoring)
      简单设计(Simple Design)
      代码集体所有权(Collective Code Ownership)
      持续集成(Continuous Integration)
      现场客户(On-site Customer)
      小型发布（Small Release）
      每周40小时工作制（40-hour Week）
      编码规范（Code Standards）
      系统隐喻（System Metaphor）

三、XP的四个核心价值

      极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

　　XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

　　XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

四、XP 带给我们的变化

　　通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗？XP认为事实并非如此。

　　一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说：“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。

　　另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

　　一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。

　　XP开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

五、我们什么时候用XP

　　XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。

　　XP方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

　　XP方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。

　　另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。

　　在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。

六、极限编程的有效实践

1、完整团队

      XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2、计划游戏

      计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

3、客户测试

      作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4、简单设计

      团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

5、结对编程

      所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

6、测试驱动开发

      编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7、改进设计

      随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

8、持续集成

      团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。

9、集体代码所有权

      任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

10、编码标准

      系统中所有的代码看起来就好像是被单独一人编写的。

11、隐喻

      将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

12、可持续的速度

      团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。