极限编程简述

在敏捷方法中，极限编程（XP：eXtreme Programming）是其中最著名的一个，它由一系列简单却互相依赖的实践组成。。。

本篇博客，对极限编程作一个简述，以及我的的一些理解，主要从如下几点进行。。。

客户做为团队成员

良性计划

简单设计

结对编程

持续集成

TDD和UAT

重构

隐喻

 

1、客户做为团队成员

关键词：面对面沟通

首先明确一点，这里的客户不只仅指为咱们产品付费或使用产品的外部客户，它还包括公司内部的业务部门，有合做关系的甲方、第三方等。

XP团队中的客户是指：定义产品特性并对其进行排列优先级的人或者团体，即今天咱们俗称的产品、业务分析师、项目经理等一类人。

它所追求的是“客户”和开发人员在同一个环境中工做。这里的环境由小到大能够是：同一个房间——距离在100米内——更远；距离越远，客户越难以融入到团队中来。

在XP中，面对面沟通，是最有效最简洁的交流方式！

 

2、良性计划

一、初始计划

关键词：肯定重要的需求，快速响应，工时预估

项目开始时，开发人员和“客户”应尽可能肯定出真正重要的需求，而不是全部的需求。由于随着项目进展，需求也处在随时或大或小的变动中。

只须要肯定真正重要的需求，保持开发方向正确便可，这样也方便对变动的快速响应和调整。

在“客户”不断编写变动需求的时候，开发人员也应该对需求进行预估。工时预估是相对的，而不是绝对的，应流出必定的缓冲时间。

若是需求太大，那么就须要对其进行拆分，直至能够相对准确的进行工时预估和详细的开发设计为止。

二、发布计划

关键词：需求可替换，随时调整

知道了开发速度后，“客户”便可知道需求的实现成本（包括人力、时间等资源）、商业价值、优先级别。

在开发过程当中，能够根据具体的开发进度、实现难易程度而不断调整需求的优先级，甚至进行需求替换，即：优先级。

初始可能对优先级等状况的判断不是很准确，但随着开发进度不断精确，预估调整也能够不断精确。

三、迭代计划

关键词：每次迭代作什么？

在XP中，通常的迭代周期为1-2周，迭代周期内需求的实现顺序取决于技术决策范畴，应采用最具技术意义的顺序来实现这些需求，能够串行也能够并行开发。

肯定迭代后，正在开发的需求则不该被更改，还未开发的需求能够根据具体状况进行调整。

四、任务计划

关键词：开发和“客户”达成一致约定

每次新的迭代开始时，开发人员应和“客户”共同约定任务计划。开发人员对需求进行任务拆分，“客户”对需求进行初始的优先级调整排列。

计划的方式能够采用任务列表、便笺、白板标示等方式，每完成一项，则应对其进行标注，对任务进度随时更新。

 

3、简单设计

关键词：关于XP的三条指导原则

一、考虑可以工做的最简单的事情

尽量寻找能实现当前需求的最简单的设计，多考虑不一样的方案，而后选择一种咱们能够实际获得和最简单的解决方案。

二、你将不须要它

只有在肯定真的须要引入某些基础结构（好比数据库、通讯服务框架）性价比更高时，再去引入它们。

三、有且只有一次

在面向对象编程原则中，有一个叫作“共同重用原则”，即消除重复的代码。

简单来讲就是将重复或类似度较高的代码变成函数，封装成一个统一的抽象集合，而后在使用时调用便可（这也将进一步减小代码间的耦合）。

 

4、结对编程

关键词：编码标准、共同全部权

在XP中，结对编程指的是由2个开发人员公用一台电脑，一我的进行编码，另外一个进行观察并寻找代码中的错误和能够改进的地方，两我的进行频繁的角色互换。

结对关系天天至少进行一次，且团队中每一个成员都应和其余成员一块儿工做参与。

这样作的好处是：知识在团队中的传播、不一样成员参与不一样的工做、可替代性较低（研究代表这样不但不会下降开发效率，切会大大减小缺陷率）。

PS：这样的开发方式如今已经不多了，但我的以为其演变至今，更像是由开发人员独立完成单元测试代码编写和功能代码编写，这样说有点拗口，换种方式：一我的身兼开发和测试开发2个岗位职责。

编码标准：在XP中，团队开发人员都遵循着相对比较统一的编码标准（你们能够脑补一下最近阿里提出的java开发规约）。

共同全部权：在XP中，团队中每一个人都拥有check out任何模块并对其进行修改的权力，每一个人并非独立的，都不会被限制在本身的专业领域。

 

5、持续集成

关键词：持续集成、可持续的开发速度

持续集成：开发人员天天都会进行屡次的check in和check out并进行merge，使用非阻塞的源代码控制工具。

        天天进行屡次系统构建（关于这点，能够参考《Google软件测试之道》中第一章第四节的内容）。

可持续的开发速度：软件开发不是百米短跑，而是一场马拉松。为了完成快速开发，团队成员必须以一种有节奏的可持续的速度前进。

 

6、TDD和UAT

关键词：TDD（测试驱动开发）、UAT（验收测试）

首先须要明白一点：编写单元测试是一种验证行为，更是一种设计行为。它的优势是：避免了至关数量的反馈循环，尤为是功能测试时候的反馈循环（即测试-提缺陷-修复-验证）的行为。

TDD：即测试驱动开发方法。在XP中，采用这种方法，它有一下几种特色：

　　 一、测试先行：在编写功能代码以前先设计测试方案和测试代码；须要明白的一点是：程序中的每一项功能都有测试来验证它的操做正确性。

　　 二、心中有数：首先编写测试代码的好处是：迫使咱们从不一样角度考虑代码设计，而不是只关注功能实现（同时考虑接口正确性、异常、边界等状况）。

　　 三、可测试的程序：先编写测试代码，迫使本身设计的程序是可测试、易于调用的，这样作的优势是：迫使程序和周边环境解耦。

　　 四、无价的文档：编写的测试代码能够做为一种无价的文档，范例，帮助其余开发成员了解如何设计、使用代码。

　　 注：这里的文档是可编译可运行的，且保持最新的版本。

　　 总结：为了使功能代码可以经过测试，迫使开发人员去作有目的的编程；为了作到心中有数，开发人员必须使得程序模块之间进行隔离，下降耦合；

　　　　   为了模块隔离，下降耦合，迫使咱们以对程序最有利的方式进行解耦合，即改善了设计。

UAT：即验收测试。是用来验证系统是否知足它所声称的具备其功能的黑盒测试方法。

验收测试是关于系统特性的最终文档。单元测试做为可编译可运行的系统内部结构的文档，验收测试是有关系统特性的可编译执行的文档。

 

7、重构

关键词：实现功能、应对变化、易于阅读和修改

在Martin Fowler大神的名著《重构》一书中，他把重构定义为：在不改变代码外在行为的前提下对代码进行修改，以改进代码内部结构的过程。

每一个软件程序都应具备三项职责：

一、可运行且可以完成全部的功能。

二、应对变化：软件是由生命周期的，在它们的生命周期中都是在不断变化的，开发者有责任保证这种变化应尽量的简单。

三、易于阅读和修改：易于阅读和修改的软件才能更加灵活和具备适应性。

从以上三点来讲，重构后的程序读起来应比以前好不少，工做的也应该更好。程序应该变得更易理解和修改，且程序结构各部分之间互相隔离。

举个例子：

重构比如用餐结束后对厨房和厨具的清理工做。第一次没有清理，用餐可能更快点，但因为没有对其进行清理，第二次作饭，你须要作的准备工做时间就更长一点，这样会促使你放弃清理工做。

若是你老是跳过清理工做，确实可使你很快用完餐，但脏乱在一每天积累。最终你须要话费大量的时间和精力，甚至代价去作清理，以使得它们适合与烹饪。

可是，饭天天都须要吃，忽略清洁工做并不能真正加快作饭用餐的速度。

PS：从这个例子能够明白，重构是必须且常常进行的！

 

8、隐喻

关键词：务实主义、全局考虑

隐喻（metaphore），是XP中最难理解的一个特性，XP本质来讲都是奉行务实主义。

简单来讲，所谓的隐喻，即从整个系统范畴来进行全局考虑，它是系统的将来景象，它使得全部单独模块的位置和特性变得更明显、直观。

若是某个模块和整个系统对比显得格格不入，那么你就应该明白，这个模块存在问题。

隐喻也能够理解为一个整体的系统总称，其特质应该是明显的，直观的（可参考《Google软件测试之道》一书中第三章第3.2.1节的Google——ACC指导原则中的特质一词）。

 

以上即关于敏捷方法中的XP（极限编程）的简述，固然，具体的一些内容须要在实践中不断理解。