你是否曾经修复了一个bug,随后又发现了一个刚修复bug有关的bug,又或是修复bug的方式引起了另一个bug？又或是修复bug的方式引起了另一个bug？当我修改bug时，我会问自己四个问题，以确保我已经仔细考虑了它的意义。每次你认为发现并修改了一个bug时，可以使用这些问题来提高生产力和代码质量。
这些问题背后的主要思想就是：每一个bug都是底层进程的一个不良表现。你必须处理这些症状，但如果你仅仅是处理这些外在症状，你就会有永远解决不完的问题。你应该找到产生 bug 的进程，并且修复这个进程。当你确定究竟发生了什么和发生这些的原因时，也许你就会明白产生 bug 的基础进程不是随机的，而是可控的。
你必须处理这些症状，但如果你仅仅是处理这些外在症状，你就会有永远解决不完的问题。你应该找到产生 bug 的进程，并且修复这个进程。当你确定究竟发生了什么和发生这些的原因时，也许你就会明白产生 bug 的基础进程不是随机的，而是可控的。
1. 这个bug的深层原因是什么？
深入问题背后实例
“它溢出了，因为下标J越界了。”
“为什么？”
“J 是 10，但数组最大下标为 9。”
“为什么？”
“J 是一个字符串长度，数组的起始下标是 0，所以字符串长度为 1 的最后一个字符的索引是 0。”
找到 bug 后，查找其他意外情况。检查程序出错时主要的程序变量的值，是否可以解释这些值。
“为什么 name 是 null？”
“为什么它总是输出错误信息呢？”
记录下你做了哪些操作，发生了哪些变化。你需要知道究竟发生了什么，这样做就意味着你时刻有一把标尺和历史记录。
2. 其他地方也会出现这个错误吗？
查看代码中使用相同模式的地方，系统地改变模式找出类似的 bug 。
“我还在其他什么地方使用长度作为下标的吗？”
“所有数组的起始下标都一样吗？”
“对于一个长度为 0 的字符串会发生什么？”
试着描述这部分代码中应该是正确的，但是这些 bug 没有遵循的规则。寻找这个不变量 [ 1 ]的过程将帮助你找到其他潜在的 bug 。
“起始偏移加上长度减去1就是结束的下标，除非数组长度为 0”。
对于你发现的每一个 bug ，你都可以解决一批 bug ，这是非常高效的。尝试用概括性的语言描述这些 bug 也能提升你对程序的理解程度，并帮助您避免在程序中引入更多的 bug 。
3. 这个 bug 后面隐藏着什么其它的 bug ？
一旦你确定了如何修复这个 bug ，你就需要考虑一下修复后会发生什么。这个执行失败的语句后面的语句也可能有问题，但是程序还没有执行到此就不知道有没有 bug ，或者有些代码因为你修复 bug 而第一次出现在程序中，这些代码也可能有问题。查看这些未执行的语句，检查代码中的 bug
“下一条语句会正常运行吗？”
当你在想程序的控制流的时候，可以弄清楚还有哪些地方程序没有执行到。
“是否有我从来没有测试过的功能组合？”
在程序中插桩（instrumentation）并不会耗费太多时间，在运行程序各个部分的过程中就可以进行检查，但是你会惊讶地发现开发者测试过的代码还有很多都不能正常运行。
“我可以测试出所有的错误信息吗？”
注意一个地方的改动可能会引起其他地方的 bug 。一些变量的局部改动可能会在执行时违反后来的假设。
“如果仅是从 J 中减去 1，当长度为 0 时，后面的语句会操作数组中 -1 位置的元素。”
如果程序已经做了大量改动，就要仔细考虑是否有必要增加另外一个补丁，或者是时候考虑重新设计和重新实现了。
3.我应该做些什么防止类似 bug 的产生呢？
问问自己如何改变编程方法，根据定义避免 bug 的出现，通过改变方法或者工具，经常可以移除整个类的错误而不用一个一个的解决 bug 。
从“ bug 是何时引入的”这个问题开始：在程序开发生命周期的哪一个阶段可以阻止 bug 的产生？
“设计是没问题的；我在编程时引入了 bug 。”
仔细检查 bug 产生的原因，考虑 bug 产生时正在运行的进程，并想想怎么改变它来阻止 bug 的产生。
“将偏移的数据类型和长度分离出来将会在编译时捕获这个错误。”
“每一个文本项可以用隐藏了下标计算的宏输出，然后我就可以一次找到它。”
不要满足于肤浅的答案。假如你对于一个 bug 的解释是，“我记不清了”，那还怎么改进这个过程，让你不再需要记住它？你可以更改编程语言，使被忽略的细节可以完全隐藏，否则你遗漏的部分会被检测到从而导致编译问题。对这个问题域，你可能使用了预处理器或者智能的编辑器，有默认值，错误检查，智能提示和快速文档。这个 bug 可能是编程团队沟通的问题，亦或是需要讨论的设计冲突。
思考发现 bug 的方式，并问问自己如何能更早发现它。测试怎么可以更严密一些？能否进行自动化测试？是否要添加代码实时检测功能，以便可以及时捕获错误信息？
这个技巧的应用
养成这样一种习惯：每当你发现一个 bug 时，问自己这四个问题，甚至你不必等到有 bug 时才使用这四个问题。
在设计和审查过程中，你都可以用这四个问题来处理你得到的每一条意见。审阅意见是潜在的沟通过程的结果，使你可以有所改进。如果你认为读者评论是错误的，比如，你可能会问是什么使你的文章没被理解，如何更好地与审稿人沟通。
设计评审和代码审查[2]是找出 bug 的强有力手段，你可以对审查过程出现的每一个缺陷都提出四个问题。如果审查彻底，前两个问题不会出现太多新的 bug ，但第四个问题可以帮助你找到方法，用来避免未来可能会出现的 bug 。
网友评论