bug的分类与定义

一.前言


我发现很多程序员都在改bug，总在改bug。但是很多人没有思考过什么是修改bug的正确方法，如何高效率的修改bug，如何避免改了一个bug又被测出另外一个bug（我称为连环bug）；还有就是，为什么我们的系统越做越不稳定了，bug越改越多了。
我总结了一下经验和大家分享。（本人一直在做windows平台下C++系统的工作，文章对C++更有针对性）

作为一个程序员，少不了要修改bug，甚至每天都要修改bug。也许你在维护一个老系统，也许你的专职就是修改bug或者你自己写的代码总是被测试人员测出问题，bug总是伴随在程序员的身边。

有的人对修改bug有抵触情绪，说：这么烂的系统，还不如重写了，要是我来写代码，哪里会有这些烂bug。
有的人麻木了，说：反正bug改不完，干一天算一天。
还有的人轻蔑的说：有bug，就改呗，哪有软件没bug的，立马动手改！


修改bug是一件非常能锻炼人的工作，一般不需要一个团队去修改一个具体的bug，所以修改bug更能提现一个人的综合能力。希望这个系列的文章能对那些天天和bug做伴的朋友有一些帮助。


二.bug的定义和分类


站在能改掉bug的角度上，我对bug做了如下分类：



我把bug分为三大类：

1.逻辑错误（有出现，不能重现）

只要是有出现的bug，不管是功能错误，内存错误的crash等，基本都是逻辑错误。那些不能轻易再现的错误都属于这一类。
要想正真改掉一个bug，请你重现它。不论用什么手段，重现它。否则，你不能对比验证你在之后修改的结果。不能验证修改的结果，你敢说你一定改对了吗。
这个系列的文章一个基本前提就是：bug一定能重现。
至于如何重现一个诡异的bug，我在以后其他系列的文章专门写点东西。

2.逻辑错误（有出现，能重现）

a.明确原因：

bug拿到手，就非常清晰的理解上下文逻辑，知道需要在哪里做什么样的修改；正确估计所做的修改对他相关模块、逻辑的影响（做到这点不容易）。
或者bug非常简单，比如：笔误、字符串拼写错误，界面图片对齐等。

b.不明原因：

这种bug的修改也是我在后面文章要大书特书的。
不明确bug产生的真正原因，只知道一个判断或者调用就有bug了，或者误解了bug产生的原因。看图中误改的箭头，这种情况下做的修改是工作效率低下的主要因素，连环bug也是这么诞生的。
一个不明确产生bug正真原因的修改，会造成无法预计的风险（看箭头）。
知道导致bug的表面调用，但是不理解代码上下文，对于直接修改表面调用造成的其他隐患没有正确估计的bug，也属于不明原因的bug。
一个只对bug表面调用逻辑做修改，不思考所有相关逻辑的行为，是要付出沉重代价的。
修改bug是非常简单的，但是明确一个bug的原因有时是很难的。

c.内存错误导致的逻辑错误：

内存错误是C++老生常谈的问题了：泄露，越界等。
由于A处的内存错误导致，即使本来正确的B处逻辑，也会出现异常状态。（有些新手可能不太理解这句话，有什么问题就问吧）
特别是那些检测不出来的内存错误：B处逻辑被你改穿了，A处还是有越界，等B处逻辑被你保护死了，又发现C处逻辑又坏了，多么可怕啊。严重影响工作效率。
内存错误的难点在于，如何认识到你手头的这个逻辑错误是由一个毫不相关的内存错误导致的。
后面的文章我会谈到怎么修改内存错误。

3.泄漏和越界,资源释放问题

a.能检测出内存错误：

有些泄露用IDE能检测出来，还可以借助boundschecker等工具。这些问题，在调试过程中就能体现。

b.不能检测出内存错误：

C++的数组越界。除非你用STL或者Boost库的数组来写代码。
C风格的数组的性格，我们改变不了。
一句话，C++是给明白人用的。
不明白的人拿起你的vc，建一个Dialog工程，定义一个成员int m_test[16];在构造函数写m_test[16] = 1；跑跑看吧。


三.修改bug的前提


再次强调，一定要重现bug，无论是谁反馈的，你要能亲眼见到bug。
有些特例：比如，前方做实施半夜1点电话你，说：重大事故啦，快改下什么什么的类型，不然人家数据要全没啦，你快改！！有经验的人，第一时间会利用vpn或者其他方式连到现场，亲眼看看。实在看不到现场的，除非你非常明确前方人员表达的意思；除非你对代码熟悉的能背诵了，早就预料到会有这一天，那你敢改就改吧。

2009-03-14
--------------------------------------------------（未完待续，下篇：bug的修改流程）----------------------------------------

欢迎大家访问我的博客，我会在博客中连载。