1.什么是极限编程
极限编程外文名叫做：ExtremePrograming, 简称XP,由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷开发中可能是最富有成效的几种方法学之一。（PS：敏捷开发是以用户的需求进化为核心， 采用迭代，循序渐进的方法进行软件开发。）极限编程和传统方法学的本质不同于在于他更强调可适应性，及面对困难的随机应变能力。当然，极限编程也有自身的缺点，并不是所有的软件开发过程都能采用极限编程。本文主要讲述极限编程的优点。
2.为什么会出现极限编程。
在传统的软件工程过程中，方法文档量过于“沉重”繁琐，因此，人们必然要寻找相对而言轻量级的方法论。但在当时敏捷方法论还并未出现，人们对轻量级的方法论的观念仅存在于”主观臆断“的阶段，认为一个完善的软件必然需要绝对完善的前期准备工作。思想是对的，但是实际的开发过程并不很令人满意。基于这一点，1993年到1999年用一种极限编程的思想诞生于Kent团队的一个项目中。随后2001年2月11号到13号，一个划时代联盟，敏捷联盟成立。在软件工程界最有影响力的非营利性组织之一。
3.极限编程包含什么内容。
①价值观
沟通（Communication）
软件工程开发过程基本都是一个团队工作，极限编程非常强调团队之间进行采用合适的方式进行面对面的交流，比如有一块白板，或者其他能表达想法的绘画工具。
简单（Simplicity）
软件开发人员有时会”眼高手低“，在做需求工程时没有做到位，在coding的过程中想要为系统设置过于多的功能，造成非常复杂的局面，以至于导致后期软件交付时客户的反感，维护费用的高昂，甚至项目报废的局面。因此设计的时候不要天马行空，仅仅设计满足你的需求的功能即可。
反馈（FeedBack）
通过不断的反馈，你的团队可以知道并修复软件存在的问题，不断地调整你们团队最终的产品。
勇气（Courage）
这里说的勇气是团队中每一个成员，在软件开发的过程中会遇到各种各样的问题，我们应该有勇气去根据自己的判断去解决面临的问题，比如我们要有勇气提出管理层的不足，我们要有勇气去停止我们觉得是是错误的开发等。不能仅仅作为一个”码农“，而是一个有判断力的程序员。
尊重(Respect)
团队成员之间需要相互尊重，相互理解，才能在项目开发过程中更好更高效的解决项目问题
②实践方法
XP的核心是下面列出的一组相互关联的团建开发实践，每个实践本身都可以单独的实行，但是在真正的开发过程中发现，这些实践中间具有相互促进的效果，因此最好放在一起进行。
面对面（Sit Together）
”沟通“是极限编程的五个价值观之一，因此大多数人同意面对面交流是最好的交流方式之一，进行无障碍的交流。
团队意识（Whole Team）
具有产品所需角色的跨职能人员组成一个团队，每个人都在一个团队中扮演自己角色，既然是为了完成共同的目标，因此团队意识是十分重要的。
信息工作场所（Informative Workplace）
我们团队所做的每一步都要对团队相关方做到透明，设立信息辐射墙更新实时信息。
精力充沛的工作（Energized Word）
精力充沛的工作意味着你能够在工作的时候完全投入进去，相对对应的，你不应该过度工作你自己，也不应该让别人过度工作你，保证自己良好健康的身体精神状态，积极乐观的生活态度。
结伴工作（Pair Programming）
之前我对此还很不理解，一个工作，一个在旁边看，这样配合工作，对那个敲代码的程序员来说有点不太公平。但实际上这样的搭配工作能够大大提高工作效率，并且大大减少后期DeBug的过程。
测试驱动开发（Test-Driven Development）
测试驱动开发简称tdd，是一种新型的程序开发方式，而不是一种测试方法。基本思想是首先编写测试代码，由测试代码来决定y要编写哪些代码。当然，也是极限编程最佳实践之一。基本步骤，先写一段单元测试代码，执行这个测试代码，不能通过编译。写所能想到的最简单的程序代码，让单元测试代码可以通过编译，再次执行这个单元测试，应该会得到验证失败的结果 （ 如果通过的话，说明单元测试没有击中要害，需要修改测试代码），写主程序代码，让单元测试可以顺利通过验证。这样就是一个测试驱动开发的流程，随后再重新进行这样的流程即可。测试驱动开发作为极限 编程思想的一种主要实践, 可以有效地让程序开发人员开发出更高品质的、经过完整测试的程序。
每周周期（Weekly Cycle）
极限编程中，团队在一周的第一天开会以反映迄今为止的进展，客户选择他们希望在那一周交付的层次，团队决定他们将如何处理这些进程。到本周结束，团队的目标就是实现客户所选择的软件阶段的测试工作。
季度周期（Quarterly Cycle）
季度周期目的是在整个项目的背景下保持每周周期的详细工作。客户根据特定季度内所需的功能为团队制定总体计划，这开阔了团队的视野，还帮助客户与其他可能需要了解功能何时可用的利益相关者合作。
懈怠（Slack）
”懈怠“的意思是，在团队每周的开发工作中加入一些简单，低级的工作量，也就是说能”缓口气“。如果团队更重要的任务时间耽误了，那么就必须将这些低级任务跳过，转入重要的工作中去。
十分钟建造（Ten-Minute Build）
十分钟构件的目标就是在十分钟内自动构建整个系统并运行所有测试。XP的创始人提出了一个十分钟的时间框架，如果有一个团队有比这个实践更长的构建，那么它就不太可能被频繁的运行，从而引入了更长的错误间隔时间。通过这种鉴别方法，贯彻到整个开发过程中，就可以为开发任务节省很多宝贵的时间。
持续集成（Continuous Integration）
持续集成就是当代码更改或者添加到更大的代码库中，立即对其进行测试，如果出了问题，那么问题可以很快锁定到新的代码块中，使得测试任务更加高效，通过这种持续集成的手段可以更快更准确的发现并修改Bug。
增量设计（Incremental Design）
增量设计就是在做一个项目之前预先做一点工作，以此来大概了解整个项目的基本情况，然后在交付特定功能时深入了解项目的各个细节。就好像我们学一门新课，上课之前先做好预习工作，对下节课需要学的内容做一个展望，那么我们在听课的时候就能更直接的学习到我们想学的内容，减少了钻牛角尖的可能，节省了很多时间。
4.个人学习心得。
总的来说，经历过过上学期《软件工程导论》的学习，对软件工程这个概念我也有了更深入的理解。之前以为的软件工程就是有个人有想法，然后这个人就开发了自己的软件。现在看来，我当时的想法也是很天真。通过撰写这篇博客，我学习了”极限编程“这种软件开发的方法，增加了我对软件过程每个环节的细节的理解，客户需求是什么，公司环境是什么，个人素质有哪些等等。希望在这学期的《软件开发与创新》和《软件工程Ⅰ》这些课中学习到更多的软件开发的流程细节，提高自己软件开发的素质。当然，以上这些仅仅是我对极限编程方法的一种浅显理解，后期如果由更多的机会接触到极限编程，那么我会把我所学到的有用的知识继续分享给大家。
