修改BUG心得

目录(?)[-]

1. 一
2. 二
3. 三

 一、

1、写第一版时就杜绝这些的发生。

2、思维要开阔，

3、修改BUG，写代码的人都很厉害，不管是写界面还是底层。不要以人做的模块的难易来断定人。

二、

还有件事，我们在做项目的时候，没有字典，规定什么的，开发起来没有统一的向导。我觉得在性能要求不是非常苛刻的情况下，有很多比如是否啊，表示状态的一些数据库中的数据最好就直接用中文来表示，因为最近改的bug中，很多都是应该显示  ‘否‘的都显示成了 ‘0’,直接就从数据库中读取出来。

做程序员最讨厌的就是修改，因为可能页面做完的时间太久，很多都不记得了。如果要是叶面比较复杂，那程序员就更头晕。所以，如果看叶面逻辑实现比较复杂的画，以后肯定要修改的，那就最好在cs文件下面写上些对这叶面的注释。

今天遇到的bug中，有个页面布局问题，就是想控件距离左边几个位置，后来领导告诉我，直接切换成中文的全角，记住是全角的中文，然后空格，这样html中就能显示出空格，而不要使用 

在 js中，没有trim这方法，今天找到一个，共享：

function trim()
  {
      return this.replace(/(^/s*)|(/s*$)/g, "");  
  }

trim()： 功能除去字符串开头和末尾的空格或其他字符。

在项目中，是有些统一规范，比如表格的字段，如果是定长，就是居中，不定长居左，钱 居右、、、、、

三、

一.前言


我发现很多程序员都在改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的修改流程）----------------------------------------

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

四、

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

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

流程如图：

1 重现

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

2 明确事发点

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

3 整理代码

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

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

4 分析原因

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

5 确定方案

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

6 修改代码

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

7 验证

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

小结

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

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