工程师13年编码、测试和调试经验大汇总

="elecfans-2012-tech-detail-content-left">

　　在《Learning From Your Bugs》一文中，我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近，我回顾了我所有的194个条目（从13岁开始），看看有什么经验教训是我可以学习的。下面是我总结的最重要的经验教训，包括编码，测试和调试三个方面。

　　编码

　　下面这些都是我经历过的会导致难点bug的问题：

　　1.事件顺序。在处理事件时，提出下列问题会很有成效：事件可以以不同的顺序到达吗？如果我们没有接收到此事件会怎么样？如果此事件接连发生两次会怎么样？哪怕通常不会发生，但系统（或交互系统）其他部分的bug可能会导致事件发生呢。

　　2.过早。这是第一点"事件顺序"的一个特例，但它确实会引起一些棘手的bug，因此我把它单独拎出来说明。例如，如果信令消息在配置和启动程序完成之前就被过早接收，那么可能就会有很多奇怪的行为发生。另一个例子：连接在被放进空闲列表之前就被标记为down。在调试这类问题时，我们总是假定在空闲列表中的时候连接被设置为down（但当时为什么不把它放到列表外面呢？）。这是我们思考的不足，没有考虑到有时候事情会过早发生。

　　3.悄无声息的故障。一些最难跟踪的bug有部分是由那些静静失败并扩展而不是抛出错误的代码所导致的。例如，没有检查代码却返回错误的系统调用（如bind）。又如：解析代码在它遇到错误元素的时候只是返回而非抛出错误。在错误状态中持续了一段时间的调用，会使调试变得更难。最好一旦检测到故障就返回错误。

　　4.If。有若干条件的if语句，if （a 或 b） ，特别是当有链接的时候， if （x） else if （y），都给我引发了很多bug。即使if语句在概念上很简单，但当有多个条件要跟踪的时候依然很容易出错。这些天，我尝试重写代码使之更简单，以避免处理复杂的if语句。

　　5.Else。有一些bug是因为没有正确考虑到如果条件为false时会发生什么而引起的。几乎在所有的情况下，都应该有一个else部分来应对每一条if语句。此外，如果你在if语句的分支中设置变量，那么或许你在另一个分支中也要设置。与此种情况相关的是标记被设置的情况。只添加用于设置的标记的条件不难，但是很容易忘了添加当标记应该再次重置时的条件。留下一个永远设置的标志可能会导致之后接连不断的bug。

　　6.改变假设。许多一开始最难预防的bug是因为改变了假设所造成的。例如，在开始时，可能每天只有一个客户事件。于是很多代码是在这样的假设下写下的。但是后来，设计改变了，允许每天有多个客户事件了。发生这种情况时，很难改变新设计影响到的所有情况。找到关于改变的所有显式依赖关系不难，难的是要找到所有隐性依赖于旧的设计的情况。例如，可能会有获取给定某一天所有客户事件的代码。其中的隐含假设是结果集永远不会超过客户的数量。关于这方面的问题我也没有很好的策略方法，如果各位有的话，还请不吝赐教。

　　7.日志记录。可视化程序做什么至关重要，特别是当逻辑很复杂的时候。确保补充足够多的（但不要太多）日志记录，这样你就可以说明为什么程序要这么做。如果一切正常，那也没关系，但要是有问题发生，你会很庆幸自己添加了这些日志。

　　测试

　　作为一个开发人员，直到要测试了我才会去处理功能。至少，这意味着每一行新的或改变了的代码行至少已经被执行过一次。此外，单元测试和功能测试都很不错，但还不够。新的功能也必须进行测试，并在类似于产品的环境中探索。只有这样，我才能说我完成了一个功能。下面是我经历过的bug所教会我的关于测试的一些重要的经验教训：

　　8.零和null。如果可行的话，确保总是用零和null来测试。对于字符串，这意味着要测试长度为零的字符串以及字符串为null两种情况。又如：测试TCP连接的断开，要在发送数据给它发送之前。不使用这些组合方法测试是导致bug出现的首位原因。

　　9.添加和删除。通常，新的功能包括能够添加新的配置到系统中——例如，一个用于手机号码转换的新的配置文件。测试它能否添加新的配置文件是很自然的。但是，我发现我们很容易忘记去测试删除配置文件是不是同样ok。

10.错误处理。处理错误的代码往往是难以测试的。最好有能检查错误处理代码的自动测试，但有时这是不可能的。我有时会使用的一招是临时修改代码，使得错误处理代码运行起来。要做到这一点最简单的方法是反转if语句——例如，从if error_count 》 0改成error_count == 0。另一个例子是拼错数据库列