聂同学

一个程序员和架构师的实践与思考

“驱动者”说

之前1谈到“驱动”这个概念。说“驱动”讲的是拆分问题的单位,现在尝试讨论下,什么样的东西,适合用来作为这个驱动者,也就是说,什么样的东西,适合用来拆分问题。

之前的我们讲,驱动者是拆分问题的单位,也是应对问题的单位、解决问题、验证解答的单位。就是说,驱动者有两个功能,一是拆分问题,一是推动问题的解决。

拆分问题方面的要求有两个 -

  1. 拆分本身的质量。拆分要易操作,最好不依赖于个人,有机械的工程方法。拆分的结果要不缺失、不重复,要容易反过来验证是否能组合回到最初的问题2
  2. 拆分出来的子问题的质量。问题要容易定义,容易应对。拆分问题的唯一目的是要让问题变得容易分别应对。如果能通过一些机械方法,直接将子问题映射为一些可以执行的任务,并到达SMART的标准,那可以说是最理想的拆分了。

推动问题解决方面,只有一个要求,就是要把解决问题的程度、进度可视化。这一方面相对简单。

下面我们用一两个“驱动”的例子,来看看下这些驱动者在各个方面的表现。

比如我们说测试驱动开发。测试案例就是驱动者,我们看看它是否符合这三个要求 -

  1. 拆分问题的质量。不太好。从要实现的用户故事,到拆分为的测试案例之间,联系并不明显。从用户故事到测试案例的映射需要程序员的丰富经验,这个过程缺乏机械性。同样的,从测试案例反过来验证组合回用户故事,也是不够直接的。通俗的讲,就是即使我完成了所有分解而来的100个测试案例,我仍然无法直接判定我是否已经满足了用户故事。
  2. 定义和应对子问题。比较好。拆分而来的子问题就是设法写出满足测试案例的代码。测试案例确定时,任务的边界也就是确定的。而对于如何写出一个通过测试案例的代码,相对比较可控。
  3. 可视化解决程度。不太好。是否能通过测试,作为问题是否解决的标注,一目了然。但这个标准只有0和1,没有中间状态,对进度的表征是不理想的。

从上面三点看,第一点比较突出,测试驱动的主要不足在于如何将用户故事稳定可靠地映射为一些测试案例。这时候BDD的理念赶来帮忙了,稍微改进一下测试驱动,将拆分为单元测试案例改为拆分为以软件行为描述的测试案例。行为描述与用户故事之间的分解-组合关系就相对更直接了。至于第三点,进度不好标度,这个问题不是很突出,因为测试驱动分解的任务粒度够小。


  1. 前一篇:“驱动”与“面向”

  2. 拆分本身可以讲一大堆,这里不展开。后续可以有一篇专文。

思维, 方法论, 架构, 过程

分享 -