极限编程XP（Extreme Programming）

极限编程简介

      极限编程（Extreme Programming，简称XP）是敏捷软件开发方法的表明。2000年，美国软件工程专家Kent Beck对极限编程这一创新软件过程方法论进行了解释：“XP是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方法。”Kent Beck建议XP应用于规模小、进度紧、需求变化大、质量要求严格的项目。它是价值而非实践驱动的高度迭代的开发过程，其价值体如今如下几个方面：

       第一，沟通（Communication）：即追求有效的沟通。XP强调项目开发人员、设计人员、客户之间等有效地、及时地沟通，确保各类信息的畅通。

       第二，简单（Simplicity）：即实现最简单的可行方案。XP认为应该尽可能保持代码的简单，只要可以知足工做须要就行，这样有利于代码的重构和优化。

       第三，反馈（Feedback）：即快速有效的反馈。要求不断对当前系统状态进行反馈，经过反馈，达到迅速沟通、编码、测试、发布的目的。

       第四，勇气（Courage）：即敢于放弃和重构。对于用户的反馈，XP程序员要敢于对本身的代码进行修改，即便有些修改可能会使得原来已经经过的测试又出现错误，可是通过团队的共同攻关，最终必然会取得满意的效果。

 

极限过程的开发过程

       与传统的开发过程不一样，极限编程的核心活动体如今需求→测试→编码→设计过程当中，所以对工做环境、需求分析、设计、编程、测试、发布等提出了新的思路和要求。

1.工做环境

   XP要求每一个参加项目开发的人都担任一个角色（项目经理、项目监督人等），并履行相应的权利和义务。全部的人都在一个开放式的开发环境中工做，最好是在同一个大房间中工做，随时讨论问题，强调每周工做40小时工做制，不加班。

2.需求分析

   客户被归入开发队伍。因为客户不具有计算机专业知识，没法用专业语言明确描述需求，因此开发人员和客户一块儿，用讲故事的方式把需求表达出来，这种故事被称为user story，即用user story表示需求。开发人员根据经验讲许多user story组合起来，或将其进行分解，最终记录在story card的小卡片上，这些user story将陆续被程序员在各个小的周期内，按照商业价值、开发风险的优先顺序逐个开发。

3.设计

   XP强调简单设计（simple design），即用最简单的办法实现每一个小需求。在XP中，没有那种传统开发模式中一次性的、针对全部需求的整体设计，这些设计只要可以知足系统客户在当前的需求就能够了，不须要考虑未来可能的变化，整个设计过程包括在整个螺旋式的项目中。

4.编程

   成对编程（pair programming）是极限编程的一大特点，即两我的一块儿使用同一屏幕，同一个键盘，共同完成一段程序的编码。成对编程的好处是，能够提升纪律性，更容易写出优质的代码，同时保证编程的流畅进行，更重要的是，可以使得整个团队更方便地分享编程经验，有利于新手的快速成长。

5.测试

   在极限编程中，测试是很是重要的一个环节，它首先要求在开始写程序以前先写好测试，其目的是为了提升软件的可测试性。XP要求开发人员常常把开发好的模块整合到一块儿，每次整合后都要运行单元测试；作任何的代码复核和修改，都要运行单元测试；发现了漏洞，就要增长相应的测试。除了单元测试以外，还要进行整合测试、功能测试、负荷测试和系统测试等。全部这些测试是极限编程开发过程当中最重要的文档之一，也是最终交付给用户的内容之一。

6.发布

   XP要求按照开发计划，每通过一个开发周期，软件就发布一次，而不是像传统的开发方法那样，整个软件开发完成后才发布。在一个开发周期内，开发人员要求客户选择最有价值的user story做为将来一两个星期的开发内容，一个开发周期完成后，提交给客户的系统虽然不是最终的产品，但它已经实现了几个客户认为最重要的story，开发人员将逐步在其基础上增长新的模块，并且在发布前软件都通过单元测试和集成测试，所以，虽然软件并不完备，可是发布的软件客户仍是能够真正使用的。

 

极限过程的价值标准

极限编程技术以沟通、简单、回馈、勇气和尊重为价值标准。

1.沟通

   构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是经过文档来完成的。极限编程技术能够被当作是开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向全部开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励常常性的口头交流与回馈。

2.简单

   极限编程鼓励从最简单的解决方式入手再经过不断重构达到更好的结果。这种方法与传统系统开发方式的不一样之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者认可这样的考虑是有缺陷的，即有时候在修改现有的系统以知足将来的需求时不得不付出更多的努力。然而他们主张“不对未来可能的需求上投入精力”所获得的好处能够弥补这一点，由于未来的需求在他们还没提出以前是极可能发生变化的。为了未来不肯定的需求进行设计以及编码意味着在一些可能并不须要的方面浪费资源。而与以前提到的“交流”这一价值相关联来看，设计与代码上的简化能够提升交流的质量。一个由简单的编码实现的简单的设计能够更加容易得被小组中的每一个程序员所理解。

3.反馈

   在极限编程中，“反馈”是和系统开发的不少不一样方面相关联的：

  （1）来自系统的反馈：经过编写单元测试，程序员可以很直观的获得通过修改后系统的状态。

  （2）来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审通常计划二、3个礼拜进行一次，这样客户能够很是容易的了解、掌控开发的进度。

  （3）来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组能够直接对于实现新需求所须要的时间进行评估而后反馈给客户。

   反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，能够经过编写单元测试，简单的证实某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户能够以定义好的功能需求为依据，对系统进行周期性的测试。

4.勇气

   极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其余问题上花费了太多没必要要的精力。勇气使得开发人员在须要重构他们的代码时能感到温馨。这意味着从新审查现有系统并完善它会使得之后出现的变化需求更容易被实现。另外一个勇气的例子是了解何时应该彻底丢弃现有的代码。每一个程序员都有这样的经历：他们花了一成天的时间纠缠于本身设计和代码中的一个复杂的难题却无所得，而次日回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。

5.尊重

   尊重的价值体如今不少方面。在极限编程中，团队成员间的互相尊重体如今每一个人保证提交的任何改变不会致使编译没法经过、或者致使现有的测试案例失败、或者以其余方式致使工做延期。团队成员对于他们工做的尊重体如今他们老是坚持追求高质量，坚持经过重构的手段来为手头的工做找到最好的解决设计方案。