XP敏捷开发方法在线视频

下面讨论典型的敏捷开发方法XP

XP不同于Windows XP操作系统

它是极限编程的缩写

强调的是轻量

强调高效，强调低风险，强调柔性，强调可预测

这样的一种软件开发方法

当然这样显得比较虚一些

下面来看

XP有四个价值观念

也就是说XP它推崇的是这四种价值观

第一，强调的是沟通

它认为大部分项目的失败

是因为沟通不到位，沟通的这种低效

所以它特别强调要采用一些有效的方法

来进行团队成员之间的沟通

第二个价值观—简单

敏捷方法本身就追求简单

那XP叫极限编程，也就是说一点都不多做

你要什么，我能满足你就OK了

不去追求过量的，去超越用户

把眼前的做好，我不怕你的变化

所以简单与响应变化并不矛盾

第三个价值观就是它追求反馈

开发者必须要获取并且重视来自

用户、系统以及团队成员之间的这种反馈

正是由于这种反馈可以让我们吸取经验

少走弯路，提高开发速度，提高产品质量

第四个就是勇气，勇气它强调的就是重构

重构实际上就是从 XP 流传开的

非常常用的一个实践活动

通过重构、通过迭代来响应变化

从而提升客户的产品竞争力

XP 有四个基本价值观念，同时它还有12个特性

这12个特性里，有一些很流行

被广大开发人员欣然接受

但另外一些可能不被大家认可

这里重点介绍几个，比如说

TDD是公认的一种非常好的

测试驱动开发方法

很多团队、很多方法都在借用

然后就是重构，简单设计

刚才提到了它四个价值观念之一就是简单设计

还有Continuous integration持续集成

持续集成目前也形成了一个很强大的潮流

还有一些Planning Game

还有这些Small Release 小型的交付

在 Scrum当中它也强调快速的

增量的迭代

也就是说每次有一个小的交付

快速地看一看其中的一些特性

第一个，计划游戏

计划游戏本身并没有得到足够的重视

可能大家觉得这个计划来自于重型方法当中

对未来的一个预测

重型方法强调这种计划的完备和详尽

XP也要制定计划，只不过要快

不过分地追求详尽

然后根据它的变化

逐步地完善

同时结合项目进展来确定下一个阶段的系统范围

当系统发生变化，当需求发生变化的时候

马上更新计划

这是一个比较虚的东西

具体怎么变，不同的项目

不同的客户，不同的开发团队面临着

这种需求是不一样的

小型发布强调开始的设计粒度要足够小

要能够尽可能早地交付

在尽可能短的周期内

以递增的方式来发布新的版本

这样就可以很容易地估计

每一个迭代周期的进度

控制工作量，可以控制风险

这一点和Scrum 的特性是一样的

这也是所有的敏捷方法所追求的一个目标

下一个特性：简单设计

它强调只处理当前需求的内容

使得设计仅仅满足当前需求

也就是说不要过度设计

尽可能的简单，发现有复杂的地方

马上删除，就是一点都不多做

TDD是一个特别有用的实践

首先来看一看

如果做过TDD测试的同学

或之前使用过一些JUnit或NUnit框架的同学

对这个红绿非常地熟

开始的时候写一段代码

这个代码是测试代码

测试代码要测的对象叫功能代码，还没有

没有的话，当然是红色的

一编译，它就编译不通过

测试框架就会报警，触发这个红线

下一步编写功能代码

然后功能代码和对它进行测试的测试代码一起工作

于是红灯变成绿灯

然后经过重构，进入下一轮的快速迭代

这种以测试单元和测试单元框架为工具的

驱动软件开发的过程，称之为TDD

这是一个典型的TDD周期

大家可以详细地来看一下

重构也是来自于XP的极为流行的实践

重构强调的就是对代码的重构

这是一个狭义的重构

广义的重构，在XP当中

它提到了对文档、对需求、对设计

也可以进行重构

不过一般讨论重构的时候

指的是代码重构

就是指在不改变它的系统行为的前提下

来改变系统内部的结构

以减少复杂性，消除冗余

增加灵活性和提高性能等等

为目的的这样的动作和行为

一般来讲，经过一次一次地重构

达到了一个什么样的境界呢？

达到设计模式

设计模式是前人的经验

借鉴于传统的建筑工程

通过不停地重构

达到了在局部增加系统的灵活性的目的

结对编程比较有意思

这个特性很受争议

很多人不喜欢，还有一些人试了试

觉得还不错，为什么说它有争议呢？

比如在实际的工作当中

老板可能说，我花两个程序员的钱

干一个程序员的活，他觉得不合适

这是一个比较现实的例子

可以说结对编程能够提高产品质量

提高代码编写质量

可以承认有这样一个功效

但实际上，它的效果，老板可能觉得不合适

他觉得不合适，他可能就不愿意推动这样一个事情

早期不叫持续集成，叫Daily Build，叫每日构建

后来把Daily Build又叫成Night Build

Build这个构建动作原来是每天做

后来改成晚上做

晚上做可以避免占用白天的资源

后来发现无论Daily还是Night都是以天为单位，不合适

因为有的时候构建可能一天好多次

于是就改了一个正式的名字

叫 Continuous Integration持续的、无级的

就像汽车变速箱那样，无级变速

通过这种持续集成

可以快速地为客户提供可运行的版本

这就是前面提到的敏捷方法当中

都强调说要快速的增量的迭代

给用户提供这种可运行版本，通过这种持续集成

可以完美地达到这样的一个目标

同时集成了一些自动化测试工具

可以让整个的持续集成自动化

自动编译，自动测试，自动发布

最近几年，持续集成，包括持续部署

得到了广泛的应用和快速的发展

好，这部分就说到这儿，谢谢大家