解析极限编程笔记

极限编程，通常成为XP，是一种针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。XP团队以可持续的步调生产优质软件。任何情况下，变化是绝对的，不变是相对的，我们不要抱怨变化的发生，重要的时要有应付变化的能力。但是那绝对不是听从别人来变化，而是自适应形势的变化。XP属于轻量开发方法中较有影响的一种方法。
四个变量：成本、时间、质量、范围
四个原则：
沟通，不仅仅子程序员和客户的直接交谈，更主要的是要求程序员要通过直接交谈而了解客户真正想要什么。
简单，程序员只需要以尽量简单的措施完成一直的工作即可，不需要考虑以后是否要对系统扩展，因为高度迭代的过程常常有反馈。
反馈，和沟通是相互联系的，反馈越充分，沟通也就越容易。
勇气，程序员要有勇气丢掉以前的工作而重新来。

快速反馈、假定简单、递增改变、拥抱变化、质量产品。这些原则对软件开发有指导作用。
快速反馈，开发人员通过短的迭代周期，得到反馈信息，并迅速检查他们前面的工作是否满足客户的需求。
假定简单，将系统开发中的每个问题以尽量简单的方法来解决。
递增改变，用一系列的小改变开解决一个大问题。
拥抱变化，解决紧迫问题的一种包容策略。
质量产品，产品质量必须得到保证，不能因为其他的原因而放弃产品的质量。

XP方法强调客户参与和测试。在XP中，客户与程序员的角色有明显的界定。他们在同一个团队，但他们要做不同的决定。客户决定“他要什么功能”，程序员决定“成本是多少”。你能明确的分清该谁做什么决定。
一个程序能够运行并不说明它已经完成了。XP尽力通过保持系统尽可能简单从而保持系统最大的适应性。在代码通过所有测试后用重构进一步改进代码。越简单代码生命周期会越长久。

极限编程使用集体的代码所有权。XP实践试图降低集体的代码所有权带来的以下风险。个人骄傲：XP实际上没有处理这个问题，除了可能鼓励将其转换为以团队为骄傲。罚不责众：结对编程和100％运行单元测试将有助于确保没有人能够私底下进行“污染”。专业知识不足：结对编程在团队中传播了知识。阅读其他人代码：编码标准有助于减少这种问题。踩脚：持续集成保证了人们即使没有重返主线也不会走得太远，测试将确保不会出现倒退。

XP指定了开放的工作区，通常是小的私人空间围绕着一个中心区域。环境可能是最后被考虑到的东西，但是往往是非常重要的。一定要保证一个小组在工作的时候不被干扰，否则就无法真正集中精力工作。

XP推荐小而频繁的发布。XP团队一直在尝试学习，他们得到的反馈越多越好。数月或者甚至数年没有发布的项目会积累许多风险，小版本将减少风险。版本应该小，但必须由意义，至少应该包括所有的特性。

极限编程（XP）团队不是在最后的“一刹那”中完成所有的事，而是采用一系列的迭代。迭代间隔是固定的，为一到三星期。迭代是有时间限制的：如果团队无法完成每件事情，他们将放弃某些特性，而不是拖延迭代的最后期限。在每个迭代结束时，客户能够看到准备发布的系统，并对所选择的故事进行验收测试。

作为极限编程（XP）软件的客户，你将在全部时间里与团队一起编写测试，回答问题和定义优先级。客户与团队一起是帮助团队尽快完成工作的重要影响因素。

迭代期间，客户有四项主要工作：回答问题，编写验收测试，运行验收测试，知道迭代。以及在版本做好时的一项准备工作（几次迭代后）：接受版本。

XP本身没有分析员这个角色，客户直接与程序员一起工作。XP争取实现让提问的人直接与可能解决问题的人交流的高效机制。
经理的几项主要工作：应付外部的团体，组建团队，获取资源，管理团队和处理团队问题。
跟踪者将跟踪三件基本的事情：版本计划，迭代计划和验收测试。你可以轻松的用简单的电子表格进行跟踪。
XP中的教练角色已经发展成为“当场”帮助团队保持进度的人。监控，执行和改变过程；指导；提供玩具；处理问题。





极限编程的12个实践是最重要的环节。

小版本
包含最有价值的业务需求。极限编程在一个或几个迭代周期结束后就向客户提供一个版本，通过频繁的发布小版本，编程人员可以从客户处获得更多的反馈信息。

规划游戏
极限编程不像传统的开发模式那样需要详细的需求，他的需求仅是从客户那里得来的一个小任务，我们称之为用户故事。用户首先编写故事，然后由程序员来估计每个故事的开发时间，用户得到程序员反馈的开发时间后来确定每个故事开发的优先级，最后由程序员合理分配故事的开发工作。
业务人员需要决定的内容：范围、优先级、版本的组成、发布的日期
技术人员决定的内容：估算、后果、过程、详细的日程计划，让大家对系统的成功信心百倍；为反馈提供一个基准。
制定计划的原则：只制定下一个阶段所需的计划（计划需要不停的进行迭代）；接受的责任（责任只能被接受，而不能被强加）；负责实现的人进行估算；忽略个部分之间的依赖关系；为优先级作计划与为开发作计划的比较—谨记计划的目的

现场客户
指的是在系统投产后真正使用系统的人。由于极限编程是一个高速迭代的的开发过程，程序员需要实时的与客户进行交流，所以必须要有现场客户，现场客户除了负责参与规划游戏，还要负责编写验收测试。业务方和开发方一定要做到相互信任，相互尊重。

隐喻
提供了一种共识和一套公共词汇表。它有助于形成对问题和系统的全新理解，并有助于指导系统的结构，方便开发人员的沟通。

简单设计
任何时候，正确的软件设计都具有下面的特征： 能够运行所有测试、没有重复的逻辑、陈述每个对程序员重要、有尽可能少的类别和方法

重构
在不改变程序行为的前提下队员代码进行改进和简化。

测试驱动开发
要求程序员对完成的每一段代码都要编写相应的自动化测试用例。测试有助于增强程序员的信心；只对有可能出错的方法编写测试代码。 不停的进行测试的方法似乎与制作网页的过程有些类似，在制作网页的过程中我们会不断的进行预览，查看在浏览其中实际的效果，而且所有的网页都是在持续集成的过程中完成的。
测试先行并不意味着我们在什么情况下都要先编写测试，然后编写代码。在Eclipse中，如果没有一定的代码，测试程序根本就是无法通过的，又来的什么正确不正确呢。而且，在编好了基本的类之后，使用自动化的工具来生成测试程序，在一定程度上也可以提高工作的效率，何乐而不为呢？

结对编程
指两个程序员坐在同一台电脑前，合作完成同一个编程工作，包括：设计、算法、编码和测试。两个人中一个为审视者，一个为执行者，这两个角色按一定的时间不断交替。一个人思考实现此方法的最佳途径，另一个应更加偏重于战略性的角度进行思考。
结对编程是一种技巧。它需要实践，不是对每个人都很容易开始。结对编程是XP中极其重要的一种技巧，因此值得培养这种习惯来利用它的好处。

代码共有
指代码在任何时候都不是有某个人独自占有和维护，任何时候任何人都有权修改代码。这样可以保证项目的稳定性，不会因为一个程序员的离开而扰乱进度。

持续集成
用一台计算机专门作集成工作。每次开发人员完成了一段时间的工作，就会对他们所作的工作进行集成。XP中的集成由测试支持。开发人员必须保持所有单元测试 100％运行。

编码标准
标准应强调沟通，并必须被整个团队自愿地采纳。这应该是任何开发团队都要要求的。

每周40小时工作制
极限编程不赞成长时间工作，加班时项目存在严重问题的征兆。XP团队需要的是可以承受的生产率水平。如果该团队重复出现无法完成自己的承诺，他们就会将问题退回来，而不是采取加班的方式。XP团队遵循“昨天的天气”规则：估计完成下一个迭代所需时间大约与本次的估计工作日相同。此规则有助于团队找到其正常的生产力水平。你无法改变时间，但是你可以改变你的任务。







敏捷软件开发
敏捷软件方法寻求迅速建立软件途径并适应不断变化的用户需求。下面看一下敏捷软件开发宣言：
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

极限编程和Scrum属于敏捷软件开发的代表。Scrum实践不像其他的软件模型一样，并没有设计、编码、软件质量等。Scrum强调程序员的自我组织，Scrum团队有30天的Sprint时间，这30天时间Scrum团队有完全的支配权力，他们可也选择开发模式，例如可以以极限编程的方式组织开发，但到30天结束的时候必须完成预期的任务。从上面我们可以看出Scrum就像一张包装纸一样，它可以封装其他开发模式的实践，所以说Scrum与许多开发模式相互兼容。

分析结对编程
结对编程在极限编程里面是最受争议的，反对者并不比支持者少。从书中了解到曾经有三人分别做过结对编程和单人编程生产力的比较，其中有两人的实验表明结对编程生产力高于单人编程，另外那组实验刚好得出了相反的结果，从实验中我们不能得出什么有力的证据表明那种方式生产力更高，所以不能通过实验的方式来证明。到现在为止没有没有一个定论到底结对好还是不结对好。所以在这一点上是仁者见仁，智者见智。我个人保持中立，我认为在一个团队当中如果大家都支持结对编程，结对之后可以相互取长补短，这种情况下还是结对编程比较好，如果团队当中都是一些独立特性的人，不习惯两人共享一台计算机，合作之后有矛盾，不能产生默契的话还是不要强行组织结对编程。

分析重构
在极限编程中，重构的目的是使程序的内部结构更加明确、合理、简单、高重用性。简而言之，就是增加代码的可读性和可维护性。重构不等于优化，这里稍微区别一下，优化的目的是要提高代码的执行效率，要提高程序的性能，但优化之后的代码可读性和可维护性不一定提高，反而还有可能降低。在极限编程中，重构和测试驱动开发是一起工作的，在测试之前要有许多自动化的单元测试用例，能随时执行来检查重构后程序行为不变性。另外，重构要依赖于自动化工具（例如，测试驱动开发的工具，或重构浏览器）。

分析测试驱动开发
研究报告显示，软件测试的花费占用软件开发成本的50%，这样的比例在重要用途的软件里会更高一些（例如，航天系统），由此可见软件测试在整个软件开发中占有多么重要的地位。我们看一下减少软件测试会给我们带来什么，首先是软件质量的下降；其次可以缩短软件开发时间，这对于时间要求比较近的项目是件好事；最后，还可以显著的减少软件开发成本。从上面三条可以看出第一条是用户所不希望看到的，最后两条是开发者的追求，在这个客户至上的时代，我们不能做或者要尽量少做让用户不满意的事。

测试驱动开发是指在编写执行代码之前，我们先编写自动单元测试用例，这些单元测试用例作为程序的一部分。测试驱动开发有5个相互作用的迭代步骤：
1)快速加入一条单元测试用例来指定一条将要编写的功能。
2)运行所有测试用例包括步骤1)中新增的测试用例，并目睹用例的失败结果，因为其对应的代码还没有编写。
3)编写代码或者修改代码使其可以通过新的测试。
4)运行所有的代码并确认他们完全通过。
5)重构或者删除重复代码。

从上面的5个步骤来看，整个测试驱动开发里有两个规定。第一，在还没有一个失败的自动测试用例前，不要编写任何代码。第二，一直保持所有测试用例的通过率是100%。

测试用例开发的相关工具包括：用来自动化单元测试的Xunit系列，模拟真正的对象行为的模仿对象（Mock Object），可以追踪已测试代码的Jprobe，能够查找还没有给测试用例覆盖其编码的Jester，还有协助重构的RefactorIT,Transmongrify及Xrefactory等。