演化架构与紧急设计: 测试驱动设计，第 2 部分

把代码编写成小的构建块会提高代码的可重用性，因此这是您应该遵守的主要设计原则之一。使用测试有助于编写可组合的方法，能够改进设计。

度量代码质量

在 第 1 部分 开头，我指出代码的 TDD 版本比后测试版本更好。我已经给出了许多证据，但是能够进行客观的证明吗？当然，对于代码质量，没有纯粹客观的度量方法，但是有几个指标能够比较客观地反映代码质量；其中之一是圈复杂度，这是由 Thomas McCabe 发明的度量代码复杂度的方法。公式非常简单：边数减去节点数，再加 2，这里的边代表执行路径，节点代表代码行数。请考虑清单 11 中的代码：

清单 11. 用于判断圈复杂度的简单 Java 方法
public　void　doit()　{　
　　if　(c1)　{　
　　　　f1();　
　　}　else　{　　　　　
　　　　f2();　
　　}　
　　if　(c2)　{　
　　　　f3();　
　　}　else　{　
　　　　f4();　
　　}　
}　

如果把 清单 11 所示的方法画成流程图（见图 1），就很容易算出边数和节点数并计算出圈复杂度。这个方法的圈复杂度是 3 (8 - 7 + 2)。

图 1. doit() 方法的节点和边

为了度量完全数代码的两个版本，我将使用开放源码的 Java 圈复杂度工具 JavaNCSS（“NCSS” 代表 “non-commenting source statements”，这意味着这个工具也度量非注释源代码语句）。

对后测试代码运行 JavaNCSS 会产生图 2 所示的结果：

图 2. 后测试完全数查找程序的圈复杂度

这个版本中只有一个方法，JavaNCSS 报告类的方法平均有 13 行代码，圈复杂度为 5.00。TDD 版本的结果见图 3：

图 3. 完全数查找程序的 TDD 版本的圈复杂度

显然，代码的 TDD 版本包含更多方法，每个方法平均有 3.56 行代码，平均圈复杂度只有 1.56。根据这个指标，TDD 版本比后测试代码简单三倍。即使对于这个小问题，这也是很显著的差异。

结束语

在 演化架构与紧急设计 系列的最近两篇文章中，我深入讨论了在编写代码之前 编写测试的好处。TDD 能够产生更简单的方法，更好的抽象，可重用性更好的构建块。

测试可以引导开发人员沿着更好的设计路径前进，纠正可能出现的偏差。设计人员的主观臆断可能对设计产生严重损害。应该尽可能避免猜想，避免意外地做出错误的决策，但是这很困难。TDD 提供一种有效的习惯性方法，能够帮助开发人员跳出错误的猜想，克服各种困难顺利地设计出解决方案。

在下一篇文章中，我要暂时把测试放在一边，谈谈从 Smalltalk 领域借用的两个重要模式：组合方法和单一抽象层 原则。