你是否曾经修复了一个 bug ,随后又发现了一个跟刚修复 bug 有关的 bug ,又或是修复 bug 的方式引起了另一个 bug ?当我修改 bug 时,我会问自己三个问题,以确保我已经仔细考虑了它的意义。每次你认为发现并修改了一个 bug 时,可以使用这些问题来提高生产力和代码质量。
这些问题背后的主要思想就是:每一个 bug 都是底层进程的一个不良表现。你必须处理这些症状,但如果你仅仅是处理这些外在症状,你就会有永远解决不完的问题。你应该找到产生 bug 的进程,并且修复这个进程。当你确定究竟发生了什么和发生这些的原因时,也许你就会明白产生 bug 的基础进程不是随机的,而是可控的。
在问这三个问题前,你需要克服面对 bug 的这种天生的抗拒,仔细分析 bug 。查看代码并解释出错的原因,从能观察到的现象开始,向后分析,不断地问为什么,直到你可以找到产生 bug 的模式。通常,你该跟同事一起做这件事, 因为解释你认为会发生的事情,将迫使你面对一些假设——这些程序是做什么的。
“它溢出了,因为下标J越界了。”
“为什么?”
“J 是 10,但数组最大下标为 9。”
“为什么?”
“J 是一个字符串长度,数组的起始下标是 0,所以字符串长度为 1 的最后一个字符的索引是 0。”
找到 bug 后,查找其他意外情况。检查程序出错时主要