1. 前言

公司准备试点施行TDD和Pair Programming,很奇妙的两个东西,都是我在7年编程经历里想都没想过,并很难接受的东西。先说TDD。TDD是一种很违背自然思考的事情,一般我们做事情的时候总是先做事情然后再来检查,所以一般都是写代码先,然后再写test case,这是很自然的想法。而TDD则要求我们将测试代码写在逻辑代码之前,囧啊。然后是pair programming。在我的认知范围内,包括我自己,应该所有的程序员都不希望在自己写代码的时候旁边有个人看着你,甚至对你写的代码指指点点。所以这两个东西在很多软件公司,是推行不开来的。但是从另一个方面来看,存在即合理,这个东西既然有人提倡(公司的CTO也是大力提倡者),那么肯定有其意义所在。周2,大家开了个会,把所有的点都过了下,会上我仔细思考了下这两个东西,发现所得颇多,这里权作下笔记。

2. TDD解决了什么

我们看这两个东西首先先要了解这两个东西解决了什么问题。就我个人理解,TDD解决的问题有两个,第一个是开发普遍测试不足的问题。我们老是会为自己找这样那样的理由、借口,来回避逻辑代码开发完成后的测试代码。第二个是设计验证问题。我们经常会遇到一个情况,那就是设计老是被改动,而我们很难在设计进行规划的时候就参与并在逻辑代码开发之前找到问题,反而直接栽进代码开发里面去了。

关于第二点,稍微解释下。一般来说我们接到设计之后,就直接进行程序设计了,然后就是开发。在这样的流程下,你很少会仔细考虑“design”这个东西。而使用TDD的一个很重要的目的就是让程序也参与到检验设计中去,在一个设计完成后,程序需要首先理解设计,然后编写test case来验证这个设计,最后才是逻辑代码的编写。

以上两点是我对TDD的看法,比较粗浅。关于TDD的领会我暂时只有这点,我觉得我还没完全明白TDD,这里就暂且带过,等以后有了实际经验再来补充。接下来我们看一下结对编程。

3. Pair Programming解决了什么

Pair Programming,结对编程又解决了什么问题。我个人觉得它解决了一个程序开发中很关键的问题,那就是review、检查。大家肯定都听说过code review这玩意,这东西其实是软件开发中很重要的一个环节。它重要在哪里,有几点:

  • 帮助大项目中的每个程序员了解并非自己负责部分的逻辑。
  • 团队协作,高效地找出代码中的问题。
  • 保证代码质量,防止单一程序员容易导致的钻牛角尖问题。

而在实际开发过程中,因为这样那样的原因,实际能做到code review,并将它做好,做出实际效果的项目团队应该是很少的。这里结对编程就能在很大程度上保证上述3个问题的解决,并减轻大型项目code review的难度和成本。

我们回顾下软件开发的流程,一般首先是设计,然后是编程,最后是review。为了保证质量,在这三个过程中首先设计和review这两个部分应该是由一个人为核心主导然后团队执行的。这样才能保证设计和review的质量。而编程我们一般都会使用coding style和comments来提高代码整体的风格一致和可读性。我想说的是,只有当上述的内容都被完美贯彻的时候,项目的代码质量才能得到完全的保障。无论哪个环节,只要有一个环节脱节了,势必会埋下这样那样的隐患。举例来说,编程的时候的coding style和comments,当执行不到位的时候,后续的review以及人员替换后的维护都会造成问题。代码很难看懂,那就别谈什么维护了。

而普通的代码review也有其缺陷,那就是对代码质量的补救是“事后型”的,什么意思呢,就是说当你发现问题的时候,问题其实已经发生了。而结对编程则能很大程度上避免这种情况的发生,问题发生的时候,结对编程的两个人至少会有一个人发现问题,并将问题扼杀在萌芽状态。

总结下结对编程和非结对编程的优缺点。

结对编程的优点:

  • 容易保证质量,高质量保证开发时段涵盖了软件开发的整个生命周期,不容易出问题
  • review及解决问题在问题萌芽状态,高效

缺点:

  • 执行要求较高,两个结对的程序员工作时间必须重合,且对人员的质量也有要求,两个不靠谱的程序员结对并不能保证质量

非结对编程的优点:

  • 工作时间自由度高
  • 团队中人员要求不至于太高
  • (我本来想写“高效”,后来想想完全不是这么回事。高效的前提是程序员都qualified,而如果程序员都qualified的话,那当然每个人都是高效的。但是如果每个程序员都qualified的话那我们的讨论也就没有意义了,因为无论使用什么开发方式,这个团队的产出质量和效率都是能得到保证的。)

缺点:

  • 几个软件开发的关键点难于长时间彻底执行,很难保证开发周期中所有时间段都被高质量开发涵盖到
  • review为事后型,即便问题被及时解决,付出的代价也比较高昂

4. 后话

以上是一些关于TDD和结对编程开会培训后的思考,写在TDD和结对编程执行之前,权作笔记,留待后考。