演化架构与紧急设计: 测试驱动设计,第 2 部分
2009-11-05 00:00:00 来源:WEB开发网把代码编写成小的构建块会提高代码的可重用性,因此这是您应该遵守的主要设计原则之一。使用测试有助于编写可组合的方法,能够改进设计。
度量代码质量
在 第 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 领域借用的两个重要模式:组合方法和单一抽象层 原则。
更多精彩
赞助商链接