“测试驱动开发”和“结对编程”是最著名的两个敏捷实践,然而许多敏捷团队并没有采用。通常大家找借口说“太忙”,没时间采用测试驱动开发和结对编程这样的实践;实际上,他们的意思是追求高质量的代码会降低生产效率。在这里,Mike Hill 解释了这种逻辑有多么错误。
Mike 告诉我们,从本质上讲,想要“更快”,必须“更好”:
你牺牲质量,能换来更多的功能吗?不仅不是这样,而且恰恰相反:你追求的效率越高,你越应该提高内部质量标准。
…
想要提高生产水平,首先提高内部质量。
然后他告诉我们为什么会这样:
所以,为什么会这样呢? 1. 因为内部质量和外部质量并不是一回事儿。
2. 因为恰恰就是昨天的产品质量唯一决定了今天的生产水平。
3. 因为打字现在不是,永远也不是编写代码的瓶颈所在。
Mike 随后展开叙述这 3 个理由。首先,他用单词“质量”阐述外部质量与内部质量的区别,外部质量可以认为是产品有多少功能,而内部质量指的是实现这些功能的代码。他这样加以区分,是为了说明想缩短市场投放时间,可以降低外部质量,但是决不能降低内部质量。
接下来,Mike 描述了“昨天怎样决定今天”,或者说已有代码的内部质量何以影响当前的生产效率。
一整天,每当你开始动手,都要依赖已有的代码。要研究的每一行代码会降低你的速度。每一个对外开放的依赖关系会降低你的速度;每一个糟糕的变量名称会降低你的速度;每一个设计时的错误决定,不论大小,都会降低你的速度。 如果你想尽可能快地工作,就需要编写干净整洁的代码。
最后,Mike 对这个常见的误区进行了反驳:即很多人认为结对编程和测试驱动开发由于“只有一半的人打字,只有一半代码是产品代码”,所以会降低产出(生产效率)。为此,Mike 列举了“编程”时常见的 11 种活动,然后说道:
请注意往电脑里打字只占列表很小的一部分,因为编程时真正有难度的是思考,而不是打字。列表中所有其它内容(可能扔东西要除外)都是关于思考的,而不是打字。 测试驱动开发可以提高生产效率,因为它有助于思考。它避免了你编写代码时从头再来和对功能的画蛇添足,减少了代码的反复研究和调试。结对编程由于同样的原因也会提高你的生产效率。两个开发者在一块并不能像分开打字那么快,但是我们并不担心:软件开发的瓶颈是思考 [不是打字],而结对编程和测试驱动开发都能提高思考效率。
Mike 概括总结了 3 个建议,可以提高团队的生产效率:
如果你想提高团队的生产效率,就照这 3 条做:
- 修改任何代码前先编写一个会失败的简短测试
- 遵循“不结对,不干活”的原则
- 所有人要认识到内部质量的重要性
如果你知道有人(或者就是你自己)认为他们“没有时间结对或者测试驱动开发”。希望 Mike 的文章能够有所帮助。
评论