也读《敏捷软件开发》--- 极限编程

写在前面：
像书中提到的迭代开发、结对编程、持续集成、持续重构等概念，在我们的实际开发中经常会用到的，有意或者无意，该书就提供了理论的支持，使得我们在以后的开发中，更能得心应手。下面对书中的要点做下记录：
--------------------------
极限编程（XP,eXtreme Programming）是敏捷开发中的一种。它由一系列简单却相互依赖的实践组成。

1.客户成为团队成员
我们希望客户与开发人员能在一起紧密的工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。

2.用户素材
就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据优先级和估算代价来安排实现该需求的时间。（也就是说：通过和用户交谈，获取其需求要点，记录这些要点和相关的实现代价供用户参考，由用户决定实现什么）

3.短交付周期
XP项目每两周交付一次可以工作的软件。每周的迭代都实现了客户的一些需求。在每次迭代结束时，会给用户演示迭代生成的系统，也得到他们的反馈。
1）迭代计划
每次迭代大概耗时两周。一旦迭代开始，客户就同意不再修改当次迭代中的用户素材和优先级。迭代期间，开发人员可以自由地将用户素材分解成任务，并依据最具技术和商务意义的顺序来开发这些任务。
2）发布计划
XP团队通常创建一个计划来规划随后大概6次迭代的内容，就是所谓的发布计划。一次发布通常需要3个月的工作。发布计划是由一组客户根据开发人员给出的预算所选择的、排行优先级别的用户素材组成。
发布计划不是一成不变的，客户可以随时改变计划的内容，如，它可以取消用户素材、添加新的用户素材或者改变用户素材的优先级等。

4.验收测试
可以以客户指定的验收测试的形式来捕获有关用户素材的细节。

5.结对编程
所有的产品代码（包括设计、编写）都是有结对的程序员（2人）使用一台电脑通过完成的。

6.测试驱动的开发方法
编写所有的产品代码的目的就是为了通过单元测试。首先编写一个单元测试，然后编写代码使测试通过。
编写测试用例和代码之间的更迭速度是很快的，基本在几分钟左右。测试用例和代码共同演化，其中测试用例循环渐进地对代码的编写进行指导。
结果就是，一个完整的测试用例集和代码一起发展起来。开发人员可以非常方便的应用这些测试用例集检查程序是否正常工作。非常方便重构后的测试工作。
为了使测试用例通过而写的代码，可以被看做是可测试的代码。这样会强烈地激发开发人员去解除各个模块之间的耦合，而方便对每一个模块的测试。因此，测试驱动开发的方式使得代码的设计耦合度降低，方便以后的开发维护。

7.集体所有权
结对编程中的每一对都具有check out任何模块并对它进行修改的权力。没有程序员对任何一个特定的模块或技术单独负责。（在实际的开发中，个人感觉采取折中的方式会好些）

8.持续集成
完成了一个功能，合并到代码仓库中，解决必要的冲突，当然，越早集成冲突率越低。

9.可持续的开发速度
团队要具备可持续发展的能力，不能透支明天的时间。

10.开放的工作空间
自由交谈，激励辩论，唯一的目的就是更高效的交互、开发出高质量的产品。

11.计划游戏
计划游戏（planning game）的本质是划分业务人员和开发人员之间的职责。业务人员（也就是客户）决定特性（feature）的重要性，开发人员决定实现一个特性所话费的代价。

12.简单的设计
XP团队使他们的设计尽可能地简单、具有表现力。这里有3条原则：
1）考虑能够工作的最简单事情（用最简单的方式完成当前的用户素材）
2）你将不需要它（只有在迫切需求时，才引入较为复杂的重型架构）
3）一次，并且只有一次（消除重复性的代码，不要出现两段相同的代码）

13.重构
代码往往会腐化。随着我们添加一个个的功能，修改过一个个的bug，代码的结构会逐渐退化。如果置之不理的话，这种退化最终会导致纠结不清，难以维护的混乱代码。

XP团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下，对其进行一系列的改造（transformation），旨在改进系统的实践活动。每一个改造也许微不足道，但是无数次的叠加，就形成了对系统设计和架构显著的改进。

在每一次细微的改造之后，需要运行单元测试以确保改造没有照成任何破坏，然后再去做下一次改造。如此往复，周而复始，每次改造都需要运行测试。通过这种方式，我们可以在改造系统设计的同时，保存系统可以工作。

重构是持续进行的，而不是在项目结束时、版本发布时、迭代结束时、甚至每天快下班时才进行的。重构是我们每隔一个小时或者半个小时就要做的事情。通过重构，我们可以持续地保持尽可能干净、简单并且具有表现力的代码。

14.隐喻
简单的理解就是，把抽象的、复杂的软件处理逻辑想象成现实世界中比较简单的容易理解的场景（当然，这个场景越有意思越好）