敏捷实践之XP极限编程

本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；

简介

• 极限编程（ExtremeProgramming，简称XP）是一种软件工程方法学，极限编程和传统方法学的本质不同在于它更强调可适应性能性以及面临的困难。
• XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
• 主要目标:降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更将导致开发成本急速增加。极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。
• 核心理念:就是“把通常的软件开发的做法推进到极致”，以便让软件开发能够达到低成本、低缺陷、高产出、高回报的效果。这也是这种方法名字中“极限”的由来。
  • 测试->TDD：在软件开发中，测试是一个通常的做法，一般都会在程序员编写完代码后，由测试工程师来进行测试。Beck把测试这个通常的做法往前推，即在程序员编写代码前，先编写单元测试代码，然后再编写生产代码，让测试运行通过。这样就把测试推进到极致，能让程序员通过自动化单元测试更快发现自己的代码是否有功能性缺陷。
  • 代码审查->pair；在软件开发中，代码审查也是一个通常的做法，一般会在程序员编写完代码后，由一两位资深程序员来审议代码的质量。Beck把代码审查这个做法再往前推，即在程序员编写代码前，再另外找一个程序员和他结对编程，在编写代码的过程中随时做代码审查。两人在结对编程过程中，还能互换角色，相互做代码审查。这样就把代码审查推进到极致，能让程序员在结对编程中更快地发现自己的代码是否有问题。
  • 集成->持续集成；比如，软件开发一般需要把一个大系统分解为若干模块，每个模块分别开发。等各个模块完成代码编写后，再做集成测试。Beck把集成测试这个做法往前推，即在编写代码的过程中，每过几小时就要进行一次自动化的集成测试，把集成测试推进到极致，能让程序员通过自动化集成测试更快地发现自己的代码是否有集成的缺陷。

四个核心价值

• 极限编程中有四个核心价值: 沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

• 沟通：XP方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性，及时的和别人沟通可能能够使问题能够更加快速和有效的解决。

• 简单：XP方法论提倡在工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。真正做到保持简单的工作其实很难的。因为在传统的开发方法中，都要求大家对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展的空间，而它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。

• 反馈：不仅是客户与项目负责人之间的反馈，还应该包括开发人员在内，做到项目所有相关人自觉的反馈，让他人知道项目进度，每个开发人员任务完成情况，做到人人都能及时知道项目的情况，人员的情况。这样所有人都能心里有数，才能做到相互配合，有效的沟通。在项目进行的过程中不可能存在一成不变的情况，及时的沟通调整方向能够更好的调整战略方针和项目的方向，技术是在一点点改变中成为一个稳定，成熟的项目。

  • 来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。
  • 来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
  • 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户

• 勇气：XP是提倡拥抱变化的，那么要积极响应变化就需要相关相关人员，特别是开发人员有勇气来面对快速开发，重新开发，代码重构等情况，重构则是要勇于改变现状，让代码脱胎换骨。

  • “系统开发中的勇气”:“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。
  • 了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。

五个原则

• 快速反馈：及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环，迅速地了解现在的产品是否满足了客户的需求。也就是需要我们持续交付，调整功能，这也是对反馈这一价值观的进一步补充。快速反馈同样适用于开发人员之间，团队人员之间，及时反馈，有效沟通。

• 简单性假设：类似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。这点下文还会继续说明。

• 逐步修改：就像开车打方向盘一样，不要一次做出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理同样适用，任何问题都应该通过一系列能够带来差异的微小改动来解决。

• 提倡更改：在软件开发过程中，在解决最重要问题时，尽量为下一次修改做好准备。开发不息，Bug不断，我们都要打从心里明白，Bug是不可能有完全修改完的一天的，所以需要不断进行更改，也不要守着最初的方案，不敢做任何变动，要为随时可能到来的改动做好心里准备。

• 优质工作:在实践中，经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，由于不影响使用就先不管；某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象，这样的坏习惯一旦养成，必然使得代码质量大打折扣。而在XP方法论中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。

13个最佳实践

• 极限编程的4个商业实践：
  • 测试驱动开发—TDD是你的商业安全网，因为测试是在编码之前完成的，所以写完的测试一定会运行失败，接下来再写代码使测试可以通过。TDD保证你的产品功能，不管公司和技术团队实现的是大规模的变更还是小规模的变更。
  • 结对编程—让2名开发人员写同一段代码，使用同一个键盘和同一台显示器。因为结对大大降低了浪费的时间和缺陷，所以能带来更高质量的代码，并带来高水平的协作。
  • 集体代码所有制和持续集成—如果每段代码不只有一个人熟悉，那么就不会有什么交流瓶颈了。把代码持续集成到一个主干可以避免重复和不匹配的代码。
  • 重构—在当时的情况下，写的代码是解决已知问题的。通常，团队巧妙地解决了他们的问题，然后持续重构和修改代码，确保代码库能以最为高效的方式不断满足业务最新的需要。

1. 团队协作(Whole Team);

2. 规划策略(The Planning Game): 主要思想就是先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划,产生的结果是一套用户故事及后续的一两次迭代的概要计划。

3. 结对编程(Pair programming):所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

   • 过于耗费人力资源，自尊心较强的开发人员也比较排斥结对编程。
   • 所有的设计决策确保不是由一个人做出的。
   • 系统的任何一个部分都肯定至少有2个人以上熟悉。
   • 几乎不可能有2个人都忽略的测试项或者其他任务
   • 结对组合的动态性，是一个企业知识管理的好途径。
   • 代码总是能够保证被评审过。

4. 测试驱动开发(Testing-Driven Development):编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

5. 重构(Refractoring):重构时一种对代码进行改进而不影响功能实现的技术，XP需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码优化更加容易。

6. 简单设计(Simple Design):提出没有重复代码，尽量少的类和方法，使用迪米特法则等，只是针对今天而言，不要因为后期可能会用到，就添加了一个现在不用的类或者方法，而不是不做可扩展性，这两者并不冲突。即使因为没有考虑很多，而可拓展性没有做到很好，XP提倡重构也能将扩展性提高一个档次，而且更精确更符合现在的需求。而传统的方式将一切考虑到位也不见得扩展性就完美，毕竟变化是不可预测的，现在考虑的扩展性在几个月后可能也用不上了，到时必然也是要重构;

7. 代码集体所有权(Collective Code Ownership):任何结对的程序员都可以在任何时候改进任何代码。团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。

8. 持续集成(Continuous Integration):团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。持续集成是指团队每天尽可能多次的进行代码集成，保证团队获取的代码都是近期统一过的代码，避免太多不一致造成冲突。而上文说的小型发布则是更多的发布测试版本，中间版本，让客户或者PM审核，确认功能开发没有错误。需要我们引入代码管理工具，版本控制工具。

9. 现场客户(On-site Customer): 作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的需要将客户请到开发现场，需要客户进行体验，确保业务功能正确。

10. 小型发布（Small Release）:XP方法论秉承的是“持续集成，小步快走”的哲学，也就是说每一次发布的版本应该尽可能的小，当然前提条件是每个版本有足够的商业价值，值得发布。由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。

11. 每周40小时工作制（40-hour Week）

12. 编码规范（Code Standards）:系统中所有的代码看起来就好像是被单独一人编写的,编码标准可以消除一些无谓的分歧。

13. 系统隐喻（System Metaphor）:创造心照不宣的词汇和列子，更形象有趣的沟通。比喻有时候更能让人更快更好的理解你的意思，而不是一堆晦涩专业术语。将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。隐喻可以帮助结对伙伴更好地沟通。

https://baike.baidu.com/item/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B/4690591?fr=aladdin
https://blog.csdn.net/liyangbing315/article/details/5387129