第Ⅰ部分 敏捷开发 第2章 极限编程概述

作为开发人员，我们应该记住，XP并非唯一选择。——Pete MaBreen
★2.1极限编程实践
极限编程(eXtreme Programming)是敏捷方法中著名的一个。由一系列相互依赖的实践组成。

★2.1.1客户作为团队成员
XP中客户的定义：定义产品特性并排列这些特性优先级的人或团体。可能是统一家公司的业务分析师和市场专家，或者用户团体代表，或者支付开发费用的人。
客户与开发人员越近，就越容易融合到团队中。

★2.1.2用户素材
关于需求的特定细节：
为了进行项目记录，了解项目需求，但不要太多，能够做记录即可。
需求的特定细节会随着时间的改变而改变，特别是看到集成到一起的系统时，因此过早的捕获细节会导致无用功；
XP中与客户反复讨论获取对需求细节的理解，但不捕获那些细节，用简短的词语进行记录，记录是为了帮助汇集，开发人员在记录边标明估算。
用户素材(user stories)：关于需求谈话的助记符，是计划工具，客户根据优先级和实现代价安排该需求的实现时间。

★2.1.3短交付周期
每两周交付可工作软件，实现涉众需求，并演示，得到反馈。
开发人员通过以前迭代中完成的工作量，为本次迭代设定预算。
计划分为：
迭代计划：2周的计划。
发布计划：6个迭代计划。

★2.1.4验收测试
验收测试在实现该用户素材之前或同时完成。
验收测试使用能够让他们自动并且反复运行的脚本语言编写。可以由开发人员或QA部门编写。
不断增长的验收测试每天都被多次运行。
★SLS：以前我对JUNIT之类的单元测试工具总是搞不懂有什么太大的用处，直到最近我对产品质量非常重视时，才意识到自动执行的单元测试的重要性。为 了保证产品质量，首先我们要准备非常多的测试用例，理想的状态是这些测试用例，涵盖用户实际使用的所有情况，所以，用例库会是非常庞大的。以前都是测试人 员直接操作用户界面，发现bug。这样做本身效率比较低。但问题是每个产品版本的发布、每次bug修改、或代码改动、功能增加、效率优化都应该执行一遍所 有的用例库，以确保质量，没有衍生错误。频繁发布版本的时候，手工测试显然效率太低。这时使用自动单元测试就会极大的提高测试效率，无论测试用例多么庞 大，都不用担心了。这也是为什么struts2好于struts1的原因，因为struts2是独立于容器的，可以进行自动单元测试。struts1就无 法实现这个功能。

★2.1.5结对编程
一个人控制键盘编码，另一个观察者寻找代码中的错误和可以改进的地方。
好处：提高效率，减少缺陷率；极大地促进知识在团队中的传播

★2.1.6测试驱动的开发方法
编写所有产品的目的是为了通过单元测试。
测试用例和代码同时的不断的发展。
为了使单元测试通过，解耦就成为必然的选择。

★2.1.7集体所有权
没有程序员对任何一个特定的模块或技术单独负责。

★2.1.8持续集成
每个程序员都会持续的chech in、check out。

★2.1.9可持续的开发速度
软件项目不是短跑，是马拉松。团队必须有意识的保持稳定适中的速度。
XP规则不允许加班，在版本发布前1周时例外。因为目标就在眼前，允许一蹴而就。

★2.1.10开放的工作空间
墙上挂满状态图标、任务明细、UML图。
在充满积极讨论的屋子里，生产率非但不会降低，反而会成倍提高。

★2.1.11计划游戏
计划游戏(planning game)的本质是划分业务人员和开发人员的职责。业务人员（也就是客户）决定特性(feature)，开发人员决定实现这一特性花费的成本。
每次迭代计划或发布计划开始，开发人员基于最近一次的工作量，为客户提供预算。客户选择那些所需的成本合计不超过预算的用户素材。
这样客户很快会了解项目进度，以及成本。

★2.1.12简单的设计
XP团队使设计尽可能的简单、具有表现力。他们不会考虑未来的用户素材。这意味着在一开始可能并不适用数据库或中间件，只有某个用户素材需要基础结构时，才会被引入。
下列XP原则对开发人员进行指导：
1.考虑能够工作的最简单的事情。
XP团队总是寻找能够实现当前用户素材的最简单的设计。
平面文件对数据库或EJB；socket连接对ORB或RMI；多线程对单线程。

2.你将不需要它。
只有有证据表明，现在引入基础结构比过一段时间引入跟合算时才提前引入基础结构。
★SLS：这与我的调优原则一样，只有当我们可以肯定某一瓶颈肯定发生，或已经发生时才进行调优，而不是在不确定问题是否可定发生时，就解决问题。

3.一次，并且只有一次。
极限编程不允许重复的代码。
导致重复的因素很多，对常见的是复制粘贴。
消除重复代码的方法有，定义函数或基类或者使用TEMPLATE METHOD。
消除重复最好的方法就是抽象。

★2.1.13重构
随着添加一个有一个特性，处理一个有一个错误，代码结构会腐化，不过置之不理，会导致纠结不清，难于维护的代码。
重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的一系列活动。
每次改造后就运行单元测试以确保没有造成任何破坏。从而保证系统可工作。
重构是持续进行的，1个小时半个小时一次，是持续的。

★2.1.14隐喻
隐喻(metaphor)是整个系统的联系在一起的全局视图，是未来的景象，是它使得所有单独模块的位置和外观变得明显直观。
隐喻通常可以归结为一系列具有象征意义的名字，这些名字提供一个系统组成元素的词汇表，并有助于定义他们之间的关系。

★2.2结论
极限编程是一组简单、具体的实践，这些实践结合在一起形成敏捷开发过程。是一种通用、优良的软件开发方法。
项目团队可以直接采用，可以可以增加实践，或者对实践进行修改后采用。