《徐昊-TDD项目实战70讲》学习笔记 -- Day 11

11｜作为工程化方法的TDD：更低的成本与更高的效能

TDD 的流程

a5a74d26cf9581064420d81cff7da89c.jpg

如上图所示，使用 TDD 的核心流程为：

• 首先将需求分解为功能点，也就是将需求转化为一系列可验证的里程碑点；

• 如果已经存在架构或架构愿景，则依据架构中定义的组件与交互，将功能点分解为不同的功能上下文；

• 如果尚不存在架构愿景，则可以将功能点作为功能上下文；

• 将功能点按照功能上下文，分解为任务项。也就是进一步将可验证的里程碑点，分解为功能上下文中可验证的任务项；

• 将任务项转化为自动化测试，进入红 / 绿 / 重构循环，驱动功能上下文内的功能实现；

• 如果重构涉及功能上下文的重新划分，即提取 / 合并组件，即视作对于架构的重构与梳理。需调整后续功能点中对于功能上下文以及任务项的划分。

• 如此往复，直到所有功能完成。

通过上述过程的描述，可以发现任务列表中的任务项源自两层分解：源自对于业务理解的功能点分解，以及源自架构愿景的功能上下文分解。

功能点分解帮助我们形成可验证的里程碑点。这些里程碑点可看作由可工作的软件（Working Software）构成的进度度量。功能上下文分解帮助我们找到正确的单元，指导我们保持良好的软件架构。

如果功能点分解错误，那么就得不到功能正确的软件；如果功能上下文分解错误，那么就得不到架构良好的软件。

TDD 的工程优势

所以，使用 TDD 开发软件对人的要求，与其他所有软件工程方法对人的要求是一样的：理解需求，明白架构。但是 TDD 提供了这样几点在工程管理上的优势。

第一，理解需求等于可以针对功能点写出测试。换句话说，写不出测试就是不理解需求。不理解需求就不要开发。在不理解需求的前提下开发功能点，只能带来负的进度。从工程管理角度上看，“判断一个人是否理解了需求”的成本极高。

第二，不写测试，除了不会写测试之外，就是没理解需求。没理解需求就去写测试，那就是瞎干，瞎干不如不干。如果整个团队都写不出测试，那么说明这个需求无法通过可管控的工程化方式交付。

可管控的工程化方式交付，意味着这个需求在实现层面上可以被执行，也就是高确定性的。在高确定性的环境下，要追求效率。

而无法通过可管控的工程化方式交付，意味着不确定这个需求在实现层面上是否可被执行，需要进入探索模式。在不确定的情况下，要追求低成本及时止损。

第三，所有软件从业人士都认为架构是重要的，但却很少有人理解架构究竟是如何发挥作用的。架构并不是停留在纸面上的框图，而是约定了构成软件系统的组件，以及组件之间的交互方式。也就是说，架构是组件职责划分的依据以及组件的交互模式。