修复bug的痛苦之旅

 

 

由于人类的思维局限性，造成任何人造制品中都可能出现错误或瑕疵。软件对精确性的高要求，以及其本身的复杂与不可视性，使得软件开发过程中引入缺陷的概率比其它行业大了一个数量级；同时，其修复缺陷的难度也高得多。

笔者在以往编码生涯中，感觉最痛苦的事情，莫过于去排除程序中的bug。修改bug本身其实并不难，真正的困难在于如何从成千上万行代码中找到它的病根。软件bug之所以被发现，是因为可以观察到其症状的表现；但是，引起症状的根源却隐藏在软件内部的任何一行或多行代码中，并不能直接看到它们。定位bug的根源，很多时候是需要极高的耐心与毅力的。

程序员在缺乏排除类似bug的经验时，只能先努力观测症状，再去猜想bug可能的根源，然后尝试修改对应的代码，之后运行之，以验证bug是否被消除。如果运气足够好话，bug的症状可能就不再出现；这意味着，程序员也许终于不必再重复上述观测、猜想、尝试和验证的过程了。

然而，猜想最终被证实大多是要经历无数次反复的。另外，很有可能，程序员甚至永远也猜不透那个bug的谜底。

改善缺陷修复效率的主要途径，一是单元测试，这是因为每个单元的代码可以控制在几百行、甚至几十行之内，一旦在单元测试中观察到bug的症状，那么，这个bug的根源只是局限在这几百行代码中而已；另外就是增量式的开发，每次只是增加几百行代码，然后就进行全面的系统测试（这便是所谓的持续验证测试），一旦发现bug，那么其根源隐藏在新增少量代码中的概率非常大（增量式开发加上持续验证，能够解决单元测试所不能解决的系统级bug定位问题）。