背景
常常被很多朋友问到关于XP的问题，如什么是XP，什么又是工程实践，跟敏捷啥关系等等这样的问题。相信这些看似简单的问题，有很多人抱有同样的疑问。
本文旨在帮助工程师了解XP的知识点，更深入的话题请参考扩展阅读，对某一话题的辩论请移步至相应辩论区的文章，本文只做基本解释，不做更深入探讨。如果有陈述谬误，请在评论区注明，非常感谢。
什么是XP？
XP是Extreme Programming的缩写，中文译为极限编程，是Kent Beck[1]等人在上世纪九十年代发明的一种软件工程方法。极限编程是一种强调团队工作的工作方式，它是多种敏捷方式的一种。与Scrum不同的是，Scrum是一种工作方式的框架，从组织到团队的设计，而XP关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用，使开发者们能够自信地响应客户需求。强调反馈环机制，客户与研发团队之间的反馈环，测试与开发的反馈环，具体代码实现跟单元测试之间的反馈环，结对之间的反馈环。极限编程认为在软件研发过程中，变化是无所不在的，人们不应回避变化，而应该适应变化，通过对反馈的检视，去适应变化。
在XP中，常见的工程实践有：
测试驱动开发 (TDD: Test-Driven Development)
也有人称之为单元测试先行。这是一种编程方式，在传统的瀑布软件开发中，人们习惯把单元测试当做测试的一部分，认为编程就是指产品代码的实现，只有在产品代码实现之后才能编写单元测试去验证代码的实现，在编程的过程中，人们更关注实现的部分，即所谓的HOW，单元测试是后置的。但是，在TDD中，单元测试被认为是描述单元需求（大部分是函数的需求）一种手段，测试用例成为一种自动化的单元测试代码，首先通过单元测试确定要实现什么，即所谓WAHT的部分，再实现产品代码，即HOW的部分，产品代码的编写始终以需求来驱动。
测试驱动开发的原理是：
- 没有单元测试，不实现任何功能代码；
- 只编写仅能代表一种失败情况的测试代码；
- 只编写恰好能通过单元测试的产品代码。
验收测试驱动开发(ATDD)
ATDD是Acceptance Test-Driven Development的缩写。很多的工程师把它理解为自动化测试驱动开发（Automatic Test Driven Development），因为在很多公司在强调测试的自动化，其实这两者之间并没有太大的联系。ATDD强调的也是需求的澄清，通过举例的手段对用户故事需求进行澄清，再接着让这些例子变成一个个的测试用例，在功能需求被实现后，用这些测试用例去验证功能实现是否满足需求，而这需求的澄清和测试用例的实现是前置在具体的开发实现之前的。因为是通过举例的形式来描述功能的需求说明，也称之为SbE（Specification by Example，中文译为实例化需求），其同样要求测试前置。可以比较着TDD的概念来理解，TDD是对函数级别的需求说明，再驱动实现，而ATDD是对用户故事的级别的需求说明，分析，再驱动实现，他们都要求测试前置，即关注WHAT。
而测试自动化是一种缩短反馈周期，实现回归测试（Regression Test）的手段。结合着持续集成系统，可以实现一键自动化的集成与部署。
结对编程
结对编程（Pair Programming），即两个人一起编写代码，共享显示器及键盘，一位同事担任的是navigator的角色，另一位是driver的角色。结对编程的前提是代码集体所有制（Collective Code Ownership），即代码为团队所共有，团队为代码的质量共同承担责任。一般人理解结对编程是两个人干一件事，是对人力资源的浪费，实则不然。因为：
- 结对编程可以及时的完成结对代码审查，减少代码的缺陷率
- 结对编程可以帮助人员的能力提升
- 结对编程可以帮助攻关
- 结对编程可以提高编程工作的专注度
想了解更多结对编程的内容，可以参考之前的文章：关于结对开发的那些事儿
持续集成 (Continuous Integration)
持续集成在XP的实践中占据着非常重要的位置。首先要了解什么是集成，然后再讨论持续的概念。集成无非就是收集、打包和验证的过程，这就是集成的概念。软件的代码由不同的人编写，需要将所有的代码从不同的位置收集到一处，然后进行编译，这就是一般SCM的概念（即软件配置管理），将编译出来的二进制文件部署到验证环境中，进行软件的验证，这就是一般传统理解的测试[2]的概念。 为了让产品可以持续地交付到客户那里，从客户处获得客户的反馈，就有必要让产品可以持续地集成，加快集成的频率，缩短集成的周期，这就是持续的概念。为了让集成能够持续地运转，我们就有了持续集成系统，如Jekins帮助我们管理一个个持续集成的任务，Git或subversion做软件的配置管理，用自动化的编译工具对代码进行打包（因不同的开发语言而不同），自动化的单元测试，自动化的验收测试。提供一个清晰快速的反馈机制等等。进而可以演化为通过持续集成系统可以对整个开发工作进行可视化，精益方法运用到持续集成的工作中，指导项目的管理等等。进而延伸到持续部署、持续交付。
如果XP的各个工程实践是珍珠的话，那么串起这些珍珠项链的绳子就是持续集成。
如何学习和实践XP
除了了解这些基本概念外，需要了解这些实践背后的本质：反馈环 —— 通过获得反馈，持续改进的方式来适应变化的能力。还有就是不断实践，这不像学习别的东西，听个概念就可以跟人辩驳，XP是一门实践性非常强的方法，与Scrum和Kanban有着非常大的不同，Scrum是组织框架设计和角色定义，Kanban适用于团队局部优化，也适用于组织层面工作流的梳理，而XP却是实打实地技术实践。小到可以从单个工程师编写代码养成良好地单元测试的习惯，再到两个人结对开发，进行可以做团队的持续集成，大到整个产品级别或系统级别的持续集成和交付。不积跬步无以至千里；不积小流，无以成江海。
结尾
最后希望本文能够对需要了解XP的同学有所帮助，也希望有更多的朋友能够一道学习，我们不只是要成为了一名把活干完的工程师，而是成为一名如何把活干好的工程师，不是成为了一名只想着构造的工程师，而是在构造之前会思考需要构造什么的工程师，我们是要制造产品，而不是次品，我们不是码农，而是匠人。
阅读原文 >
转载请注明原文出处，谢谢
– EOF –
