如何修改bug（二）-bug的修改流程

上篇中我对bug做了3大分类：能重现的逻辑错误，不能重现的逻辑错误和潜在的内存错误。

 

这篇文章是我总结关于逻辑错误的修改流程，也算是后面文章的一个总领。

流程如图：

 

 

 

1 重现

 

再次强调这个是修改bug的前提。

 

2 明确事发点

 

就是明确导致一个bug产生最直接的一个调用或者一个判断。
明确了事发点后有两种情况，就是上图中的分支。
有些bug，在明确了事发点后就立刻知道原因了，这个大家都有体会；有些就不是这么简单了。
定位事发点的方法下篇文章有详细介绍。

 

3 整理代码

 

有些事发点逻辑错综复杂，一点注释也没有，也没有文档，或者代码风格很差。整理下代码，能减缩进就减点，太长的函数分割一下。。。就是为了提高阅读性。

因人而异，如果你觉得你的阅读能力超强，不整理也无所谓。
但是千万不要自作聪明的就开始做点“保护”,这个步骤不要让逻辑受一点影响。

 

4 分析原因

 

具体情况具体分析。这个步骤有时候是最难的，但是一定要明确原因。不明原因或者误解原因bug的修改后果是有极大风险的。
可参考《如何修改bug（一）-bug的分类和定义》。

 

5 确定方案

 

可行性、所做修改对其他模块和逻辑的影响需要周密思考、测试和验证。有些方案看上去很好，正真做进去了才发现时间白花了。在解决一些关于性能方面问题的时候往往会发生拿错方案的惨案。
有时候方案很多，都可行，难以抉择，那就具体情况具体分析了。

 

6 修改代码

这一步，是所有步骤中最简单的，就是码字。

 

7 验证

程序员保证自己工作效率和质量的关键步骤。你不想总被别人测出问题吧，或者你也不想问题最多的模块总是你在改的吧。

 

小结

 

bug千奇百怪，不是每个bug都需要经历所有流程的。每个步骤都有它的难点。
有些bug难在事发点的定位，比如多线程，异步逻辑中的bug；
有些bug难在原因很难分析，多数是你看不懂代码；
有些bug难在你不敢改，那是你的修改方案没有做好充分的分析。
。。。
其实会者不难，后面我会细细道来，和大家一起分享。

2009-03-18
--------------------------------------------------（未完待续，下篇：明确事发点）----------------------------------------
我的博客

如何修改bug（一）-bug的分类和定义