防御性编码和单元测试“交通规则”
我们三个人的家中有四个青少年驾驶员，很快还会增加一个。不用说，我们非常熟悉在驾驶员培训班中灌输给我们这些新驾驶员的防御性驾驶技术。因为在我们的青少年驾驶员短短的开车期间，他们看到了打手机的男人闯红灯、女人在拐弯的时候化妆，以及业务主管在早晨上班的路上读报。所以孩子们很快学会如何注意可能会发生事故的区域以及如何避免这些事故。 大多数司机接受过防御性驾驶技术的教育 —— 这有很好的理由 —— 但是并不是所有开发人员都接受过防御性开发的教育，特别是那些没有用汇编语言进行过多少开发（如果不是完全没用过的话）、也没有因内存约束和处理器限制而关心过编写极其紧凑的代码的年轻开发人员。本文讨论防御性编码和单元测试概念，它们可以帮助开发人员更快生成更好的代码并且缺陷更少。 捕捉错误、问题和缺陷的最佳位置是在开发周期的早期。图 1 展示了最容易出现缺陷的地方，以及最容易发现它们的地方，并包括了修复这些缺陷的成本（这些成本是针对 1996 年的 —— 今天的成本显然更高）。 当然，比在编码阶段找到缺陷更好的是在一开始就防止它们。防止缺陷应该是开发人员最优先考虑的。我们将分析几个让开发人员可以在编码和单元测试时防止并检测缺陷的简单的、经过证明的方法。 防止缺陷（特别是系统性缺陷）的最有效方式是仔细检查编码所依据的设计。由设计缺陷导致的缺陷 —— 虽然一般不是很多 —— 通常修补成本是最高的。事前花很少的时间针对以下几点对设计进行检查可以得到显著的长期回报。 设计是否有任何不清楚或者混乱的部分？如果是的话，在编写任何代码 之前 澄清这些问题。否则，您可能以一种方式解释一个设计需求，而同事则以另一种方式解释它，从而得到不兼容的实现。 如果您的代码要访问同时被其他组件访问的数据，那么保证您的设计可以处理这种情况。同时，检查设计的安全问题（请参阅 参考资料）。 如果您的代码严重依赖于其他应用程序的代码，那么您对那个应用程序是否熟悉到可以对设计进行检查？考虑在您的设计检查小组中加入熟悉该产品的一个开发人员。在 设计阶段 发现的集成问题可以得到最有效的处理。 如果您的代码是以前版本的一个升级，那么是否有会使升级失败的参数或者其他选项改变？有哪些其他产品与新代码交互或者集成 —— 如果这些产品本身也改变了呢？还有，您的代码是否容易安装？ 您的代码是否会在新版本的操作系统或者数据库上运行？您是否知道这些新版本中加入了哪些改变以及它们是否（及如何）影响您的代码？ 设计是否结合了可测试性？虽然您可能认为可测试性问题不是您需要关心的，但是事实上单元测试 是 开发人员的责任之一 —— 几乎所有使执行功能测试和/或系统测试更容易的任何事情也会使单元测试更容易执行。 下面是 可测试性 领域内容的几个例子（更多内容请参阅 参考资料 部分）。
再多想一想您肯定可以在这个清单中加入更多的内容，特别是那些对您的产品或者组织特定的内容。 当您完成对设计的检查后，就轮到编码了。就让我们面对它，除了设计错误外，编码是惟一引入缺陷的地方。无论如何，您的测试程序和客户是不会加入缺陷的 —— 只有 您 会。我们都知道时间很紧张，但是如果您没有时间在第一次就把它编写正确，那么您怎么能找到时间去修正它呢？花上一些时间，这会使您在以后的编码工作中更轻松。 防止缺陷的最好方法之一是使用编译器。令人恐惧的是，开发人员在编译时通常选择使用最低程度的警告输出，所以请启用编译的全部警告 —— 把即使将编译器配置为检查 所有方面 编译时也不产生一个警告当成编写代码的一个挑战。此外，对代码使用多种编译器使很多程序员获益 —— 这种方法有时会捕获不同的语法错误。 下面我们将抛砖引玉介绍几个好的编码习惯。我们不是要为您定义“最佳编码习惯” —— 我们只是要您形成自己遵守的代码编写习惯。下面是几个供参考的最佳习惯的例子。 您是否有一组可接受的默认值，特别是对于可能被用户、其他组件或者其他程序有选择地修改的数据？同时，我们强烈要求您列出在最外围例程中要使用的所有本地变量，然后再专门初始化它们。这样不会对您编写代码时的想法留下任何疑问。虽然这可能要多花一些时间并且像是没有理由地增加了几行代码，但是与只是在“运行中（on the fly）”声明本地变量相比，大多数优化编译器不会对此生成任何额外的运行时代码。清单 1 显示了在一个例程中最初几行代码的一个例子： 清单 1. 初始化本地变量
如果您有一个编码标准文档，就使用它。您可以在 Internet 上找到许多种编码标准。找到一种简单的、切中要害、并为您留下一定的活动空间的标准。Sun 的网站有一个关于 Java 编程的编码规范的文章（请参阅 参考资料），它给出了拥有标准的下列几点理由：
即使不赞成“标准”的想法，至少采用这个简单的建议：对变量名使用“匈牙利命名法”，这会使您的代码更容易阅读和维护（有关匈牙利命名法的说明请参阅 参考资料）。 在调试时有一种会制造麻烦的情况是：调用程序屏蔽（或者覆盖）一个表示错误的返回代码。一定要想好您要向调用您的代码的例程返回什么值，并保证从您所调用的例程返回的所有错误代码都得到恰当处理。如果返回代码
这一点怎么强调也不过分：对每个例程使用单点退出 —— 就是说，没有多重返回！这是最容易忽视的、也是您可以采用的最好的习惯。如果例程只从一个地方返回，那么就可以用一种非常容易的方法保证在返回前完成所有必要的清理工作，这也使调试更容易。清单 2 显示了一个包含多重返回的代码示例。注意重复代码、甚至忘记“清理”项目（如红色突出显示的文本所示）是多么容易。 清单 2. 单点退出示例
在第 15 行， 清单 3 显示了一种更好的方法： 清单 3. 单点退出示例 —— 修正后
这是一个简化的例子，但是请注意遵照这种习惯有多么容易，以及这样做的好处。 要记住，您的客户对您的产品有与您不一样的想法。他们会在一个您的小组很可能从来也没想到的 —— 或者至少是没有可能测试的 —— 环境中安装它。他们会以您从来没有想到过的方法使用它，并以您意想不到的方法配置它。下面的列表有助于帮助您保证他们不会发怒：
在本文中，我们所说的 单元测试 是开发人员在自己的代码正确编译后、在交给功能测试小组之前进行的所有测试和分析。正如我们在 这只是一个测试 中提到的，主动进行单元测试并 在测试时像一位测试者那样思考（即，必须往坏处想、热衷于破坏并喜欢恶作剧）是很重要的。下面是在单元测试时要记住的几件事。 第一种，也是最容易的分析代码的方法是让别人替您做 —— 或者像在这里一样，让其他 工具 替您做。有一些不同的静态代码分析工具可用，从综合性的工具 —— 一些开发机构实际上在他们的“编译”环境（这可是需要购买的）中加入了这样的工具 —— 到其他可以免费从 Internet 上下载的工具。有关可用的静态代码分析工具的信息请参阅 参考资料。 当您准备运行代码并检查缺陷时，要记住往坏处想。这些缺陷是您所创建的或者由您忽略的代码产生。下面是一些帮助您找到代码中缺陷的提示：
如果操作“b”在操作“a”之前发生会怎么样？就算您 认为 它不会发生 —— 您能 使 它发生吗？如果是的话，可以打赌您的客户会使它发生的。最好现在找出来，而不是在修复成本更高、并听到客户报怨您的软件质量糟糕之后再去做。 我们在前面 发现缺陷 中讨论了脚手架代码。如果是为自己的使用需要而创建的，一定要将它交给验证工程师。可能您提供的脚手架代码使他们可以很快地开始测试您的代码，或者至少使他们更好地理解当其他组件存在时可以预期什么。 如果您的产品有保护性的安全功能，那么您必须测试它们。提供可以创建您想要防止的情况的脚手架代码是很重要的：您必须能够创建系统试图防止的那种情况。 脚手架代码的另一个简单例子是提供操纵队列的代码。如果您的产品使用队列，那么想像如果有一个可以在运行时从队列中增加或者删除项、破坏队列中的数据（以保证适当的错误处理）等等的工具会有多方便。 使用源代码级的调试程序是进行彻底和成功的单元测试的关键方法。开发人员应该与他们的调试程序共生死。不幸的是，对源代码级的调试程序的充分了解和使用是一种正在消亡的做法，尽管这些调试程序的好处远远超过任何学习曲线。简而言之，我们强烈鼓励您全面学习一种调试程序。下面是用源代码级调试程序对代码进行单元测试的几种方法。您可以：
验证工程师是测试知识的很好来源。他们可以给您指出要测试什么并帮助您了解可以在代码中加入什么以帮助他们测试（如代码钩子）。此外，您可以向他们展示如何使用您的脚手架代码。他们还会很有兴趣了解您认为在测试中哪些应该是自动化的 —— 如果您某些事情做了不止一遍，那么他们也会。 现在是进行小测试的时候了。让我们看看您是否用心了。 您希望检查一个整数的值是否为
不过，如果您对代码进行“手指检查”，并且把代码写成了下面这样会出现什么情况呢？
这个失误是一个缺陷，但是只有在运行时才能捕获它 —— 可能需要相当的调试努力才能找到它。编译器会轻易放过您的代码，那么如何防止这种错误发生？ 答案
因为这种方法保证您可以在编译代码时立即捕捉到问题，所以它是首选的技术。虽然它看上去有些笨，但是代码可以编译并运行得很好。然而，当您“手指检查”代码时就可以立即看到好处了：
可是编译器不喜欢这样，因为 您还可以在检查 null 指针时使用这个技巧。看下面的代码：
如果您偶然将它“误写”成下面这样会发生什么呢？
您可能不会得到想要的结果。而改用下面的方法您会得到与我们刚描述过的同样的“编译器保护”：
您可能预计会有一个长的小结，把我们所讨论的所有内容重新概述一遍，然后是请您尽可能多地采用我们的建议。冒着让您失望的风险，为保持简明扼要我们做了一个相当简洁的归纳：要么现在去做，要么以后花 多得多 的代价去做。换句话说，您在开发周期的早期在测试和预防代码缺陷上花的时间越多，您在以后节省的时间和金钱就越多。这就是防御性编码的意义。它就是这么简单。
关于作者: Scott Will、Ted Rivera 和 Adam Tate 是 Tivoli Systems Software（IBM 的一个部门）的质量保证经理。他们有开发、验证、客户支持、专业服务和其他相关技术领域的背景。 |
