您的位置:知识库 » 软件工程

敏捷咨询工具箱(二)──OO训练营

来源: infoq  发布时间: 2011-01-03 21:36  阅读: 801 次  推荐: 0   原文链接   [收藏]  

犯错误是最好的学习方式。                 ──莎伦·德雷珀

  背景

  我们为客户提供咨询,刚开始做了很多敏捷的实践,包括:持续集成、测试驱动、用户故事需求分析、迭代开发等等之后,发现如果再想深入下去,就会面临一些“硬骨头”:遗留系统和开发设计能力的问题。在一些客户那里,他们产品有10多年了,但是很少有人新加程序文件,写代码习惯于复制粘贴,都是在已有的类和函数上修修补补。团队缺少追求好代码的品质和能力,到处是大函数,上帝类(超大类,任何功能变化都要修改此类),重复代码,混乱逻辑,开发和维护成本太高。作为一个顾问,如何才能从根本解决这样的开发设计能力问题呢?

  在ThoughtWorks,如果招聘了一个没有经验的开发人员,会把他们送到印度的TWU(ThoughtWorks University)培养2-6个月,OO训练营是开发人员的主要课程之一。它专门用来训练开发人员如何使用面向对象,如何进行测试驱动开发。通过这样的训练之后,开发人员可以很快的掌握面向对象开发和简单设计能力,养成追求好代码的品质。所以,我们也为客户的团队引入了TWU的OO训练营活动。

  活动方式

  OO训练营的培训方式和我们传统的“填鸭式”教育完全相反。它采用的是苏格拉底式教学法,顾问不会给你任何标准答案,而是通过问题的引导,让学员自己一步一步找到最佳的解决方案。我的OO训练营的组织方式一般是:

  一、顾问提出需求

  顾问在训练营活动会扮演着客户的角色。活动一开始的时候,会以客户的身份提出一个需求,让大家去完成。例如:要求建模一个长方形。

  二、简单设计

  以分组讨论方式做一个简单设计,一般从如下三个方面进行设计。

  1. 类名是什么?
  2. 类的职责是什么?对于复杂需求,可能会要求画一个简洁的UML对象关系图。
  3. 类的测试用例会有哪些,并且找到第一个测试用例

  讨论结束之后,每组介绍一下各自的讨论结果。通过分组讨论和顾问的引导,对建模一个长方形需求一般会得到如下的设计结果:

  1. 类名是: Rectangle
  2. 类的职责是计算周长和面积
  3. 计算周长的测试用例:
    a. 正常场景。如果长是2,宽是3,那么周长是10
    b. 异常场景,宽为0的情况。如果长是2,宽是0,那么应该抛出异常
    c. 异常场景,宽为负数的情况。如果长是2,宽是-3,那么应该抛出异常

  这些测试用例完全是由学员自己设计出来的,没有标准答案。作为顾问只是引导大家,让每组的测试用例更具体和全面。假设没有一组学员没有考虑到异常情况的测试用例,这时也也不用指出来,等后面代码展示的时候,再指出这个问题,因为犯错是最好的学习方式。

  三、测试驱动(TDD)开发

  学员根据设计和讨论的结果,用测试驱动的方式进行结对编码开发。要求先写单元测试,写完一个单元测试之后,运行测试失败,然后再去写业务代码。如果没有失败的测试,不允许写一行业务代码。这样严格的要求,让大家养成测试驱动开发的好习惯。

  两个人一组使用结对方式进行开发,要求使用乒乓式的结对方法。假设是A和B进行结对开发,A先写一个测试用例,编译通过但是测试失败。然后把键盘和鼠标交给B,B写业务代码,让测试通过,然后为A再写一个失败的测试。通过这种乒乓的方式,一个人写测试用例