Actionary

A man is valued by his works, not his words!

敏捷扫盲之XP(Extreme Programming)篇

背景

常常被很多朋友问到关于XP的问题,如什么是XP,什么又是工程实践,跟敏捷啥关系等等这样的问题。相信这些看似简单的问题,有很多人抱有同样的疑问。

本文旨在帮助工程师了解XP的知识点,更深入的话题请参考扩展阅读,对某一话题的辩论请移步至相应辩论区的文章,本文只做基本解释,不做更深入探讨。如果有陈述谬误,请在评论区注明,非常感谢。

什么是XP?1

XP是Extreme Programming的缩写,中文译为极限编程,是Kent Beck2等人在上世级九十年代发明的一种软件工程方法。极限编程是一种强调团队工作的工作方式,它是多种敏捷方式的一种。与Scrum不同的是,Scrum是一种工作方式的框架,从组织到团队的设计,而XP关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用,使开发者们能够自信地响应客户需求。强调反馈环机制,客户与研发团队之间的反馈环,测试与开发的反馈环,具体代码实现跟单元测试之间的反馈环,结对之间的反馈环。极限编程认为在软件研发过程中,变化是无所不在的,人们不应回避变化,而应该适应变化,通过对反馈的检视,去适应变化。 Alt 3

在XP中,常见的工程实践有:

测试驱动开发 (TDD: Test-Driven Development)4

也有人称之为单元测试先行。这是一种编程方式,在传统的瀑布软件开发中,人们习惯把单元测试当做测试的一部分,认为编程就是指产品代码的实现,只有在产品代码实现之后才能编写单元测试去验证代码的实现,在编程的过程中,人们更关注实现的部分,即所谓的HOW,单元测试是后置的。但是,在TDD中,单元测试被认为是描述单元需求(大部分是函数的需求)一种手段,测试用例成为一种自动化的单元测试代码,首先通过单元测试确定要实现什么,即所谓WAHT的部分,再实现产品代码,即HOW的部分,产品代码的编写始终以需求来驱动。

Alt

测试驱动开发的原理是:

  • 没有单元测试,不实现任何功能代码;
  • 只编写仅能代表一种失败情况的测试代码;
  • 只编写恰好能通过单元测试的产品代码。

验收测试驱动开发(ATDD)

ATDD是Acceptance Test-Driven Development的缩写。很多的工程师把它理解为自动化测试驱动开发(Automatic Test Driven Development),因为在很多公司在强调测试的自动化,其实这两者之间并没有太大的联系。ATDD强调的也是需求的澄清,通过举例的手段对用户故事需求进行澄清,再接着让这些例子变成一个个的测试用例,在功能需求被实现后,用这些测试用例去验证功能实现是否满足需求,而这需求的澄清和测试用例的实现是前置在具体的开发实现之前的。因为是通过举例的形式来描述功能的需求说明,也称之为SbE(Specification by Example,中文译为实例化需求),其同样要求测试前置。可以比较着TDD的概念来理解,TDD是对函数级别的需求说明,再驱动实现,而ATDD是对用户故事的级别的需求说明,分析,再驱动实现,他们都要求测试前置,即关注WHAT

Alt

而测试自动化是一种缩短反馈周期,实现回归测试(Regression Test)的手段。结合着持续集成系统,可以实现一键自动化的集成与部署。

结对编程

结对编程(Pair Programming),即两个人一起编写代码,共享显示器及键盘,一位同事担任的是navigator的角色,另一位是driver的角色。结对编程的前提是代码集体所有制(Collective Code Ownership),即代码为团队所共有,团队为代码的质量共同承担责任。一般人理解结对编程是两个人干一件事,是对人力资源的浪费,实则不然。因为:

  • 结对编程可以及时的完成结对代码审查,减少代码的缺陷率
  • 结对编程可以帮助人员的能力提升
  • 结对编程可以帮助攻关
  • 结对编程可以提高编程工作的专注度

想了解更多结对编程的内容,可以参考之前的文章:关于结对开发的那些事儿

持续集成 (Continuous Integration)

持续集成在XP的实践中占据着非常重要的位置。首先要了解什么是集成,然后再讨论持续的概念。集成无非就是收集、打包和验证的过程,这就是集成的概念。软件的代码由不同的人编写,需要将所有的代码从不同的位置收集到一处,然后进行编译,这就是一般SCM的概念(即软件配置管理),将编译出来的二进制文件部署到验证环境中,进行软件的验证,这就是一般传统理解的测试 5的概念。 为了让产品可以持续地交付到客户那里,从客户处获得客户的反馈,就有必要让产品可以持续地集成,加快集成的频率,缩短集成的周期,这就是持续的概念。为了让集成能够持续地运转,我们就有了持续集成系统,如Jekins帮助我们管理一个个持续集成的任务,Git或subversion做软件的配置管理,用自动化的编译工具对代码进行打包(因不同的开发语言而不同),自动化的单元测试,自动化的验收测试。提供一个清晰快速的反馈机制等等。进而可以演化为通过持续集成系统可以对整个开发工作进行可视化,精益方法运用到持续集成的工作中,指导项目的管理等等。进而延伸到持续部署、持续交付。

Alt 6

如果XP的各个工程实践是珍珠的话,那么串起这些珍珠项链的绳子就是持续集成。

如何学习和实践XP

除了了解这些基本概念外,需要了解这些实践背后的本质:反馈环 —— 通过获得反馈,持续改进的方式来适应变化的能力。还有就是不断实践,这不像学习别的东西,听个概念就可以跟人辩驳,XP是一门实践性非常强的方法,与Scrum和Kanban有着非常大的不同,Scrum是组织框架设计,Kanban适用于团队局部优化,而XP却是实打实地技术实践。小到可以从单个工程师编写代码养成良好地单元测试的习惯,再到两个人结对开发,进行可以做团队的持续集成,大到整个产品级别或系统级别的持续集成和交付。不积跬步无以至千里;不积小流,无以成江海。

结尾

最后希望本文能够对需要了解XP的同学有所帮助,也希望有更多的朋友能够一道学习,我们不只是要成为了一名把活干完的工程师,而是成为一名如何把活干好的工程师,不是成为了一名只想着构造的工程师,而是在构造之前会想要构造什么的工程师,我们是要制造产品,而不是次品,我们不是码农,而是匠人。

– EOF –


  1. 更多内容可以参考Extreme Programming: A gentle introduction

  2. Kent Beck也是敏捷宣言的十七位发起人之一,Test-Driven Development: By Example的作者

  3. 图片来源https://en.wikipedia.org/wiki/Extreme_programming#/media/File:Extreme_Programming.svg

  4. 可阅读Uncle Bob的The Cycles of TDD

  5. 这里指狭义理解的测试概念,测试的概念可以往验证、探索等各个方向延伸讨论,这里不做展开。

  6. 图片来自http://www.continuousautomation.com/

Comments