不择手段除掉你----BUG

                                                                        不择手段除掉你----BUG

导读：

  “对于程序员而言，最大的痛苦，莫过于去修别人的BUG”

    曾经一段时间自己在拼命的去修别人的BUG，那种对功能点的不明确性，让我很抓狂,有过那样的经历，所以深有感触。但是对于一个企业，应该去感谢测试部扔出来的这些BUG，因为她让你的问题在没呈现在用户之前，提早发现了。试想，如果一个一个模块开发出来直接跑出去，那会给公司带来多大的麻烦，最主要的是公司的负面影响力就大大打了哦。所以，一定要让自己喜欢修BUG，因为她比开发新的东西更重要。

     记得自己刚做开发的时候，只要一出BUG第一件事情就是直接把BUG直接扔给google，然后就按照里面说的去解决的方案，按照里面说的去干，有的时候问题连BUG的详细描述都没看清；可是后来当我离开Google的时候，当我离开百度的时候，我很迷茫，我以为我会死掉，后来我发现，原来我可以离开Google，在这个蜕变的过程中，自己也总结了一些小窍门，希望对大家有用。

     嘻嘻，好了，不废话了，本文主要分3部分：BUG是在一个项目成型之后显示出来的以及他的一些特点第二部分我认为针对一些问题一些可行的解决方案，最后是修改BUG一般的流程。

 

 

 

以下是自己在修BUG的一些感触，可以算是遇到BUG的一些特点吧，那出来跟大家分享下：

"当你遇到BUG的时候你会干什么？你会想什么？"

 

      1什么浏览器呀

      2什么操作系统呀

      3怎么浮现呀

      4.是不是配置的问题，因为系统里面那么多配置的问题

      5.那项目的时候那个版本呀？

      6.暂缓可以不？

      7.这个BUG以前解决过吗？以前解决的时候记录了吗？

      8.解决这个BUG大概的位置能定位吗？需要多长时间

      9.这个BUG的责任人是谁，直接转给他嘻嘻

      10.测试人是谁，这个功能点没遇到过，直接找他浮现

      11.经验告诉我这个肯定是SQL语句。。。。

      12直接Google

      13晕死 这个BUG怎么还标记着紧急呀

      14这个BUG这么怎么从没见过呀？

    15。。。。。。

 

 

   看到一个BUG会让你联想到这么多，看来你对她，跟我对他一样，恨之入骨呀。。。。。呵呵，那么我们很有必要了解下BUG的一些特点了哦。

以下是ME总结的一写BUG基本特点，不知道全不全，不全的可以留言给我，嘻嘻，谢谢。

 

BUG特点一：“BUG是不允许被暂缓的，OK？”

 

   在一个闷热的夏天的下午，大家都昏昏欲睡，我在一个角落里，看着屏幕，在本子上记着什么，突然她来了，打破了整个小屋的安静，她是来找我头理论的，

“你怎么把我提的BUG暂缓了？只改下图标就可以了，就给我暂缓”，“我没呀”,我听见我头的头似乎在旁边笑，"我头用自己的帐号登进去，然后看那个刚

暂缓的BUG，“只改下图标就可以了”，“行，张姐，我给改还不行吗”，她像是打胜仗似的走掉了，脸上还带着微笑，我在我工位上偷偷的看了头一眼，

幸好他没对我怒。。。。。。整个小屋就沸腾了，她的你都敢暂缓？从那我就记住了“BUG是不允许被暂缓的” .

 

 

BUG特点二："BUG是怎么产生的？多次反工，等于无功,并且这是提高你工作效率的直接捷径"

    当然是你写出来的，他写出来的，不管是谁写出来的，但是现在比较麻烦的是你必须去修改这些BUG。一次性把业务搞清楚对你很重要，避免很多

需求细节。“未雨绸缪，你要知道，需求错了是你制造出的最大的BUG”，如何让你的需求是相对准确的，可以看上篇文章：

 http://www.cnblogs.com/muer/archive/2011/05/15/getrequirement.html

 

 

BUG特点三：“WOW,又是这个BUG”她总是重复出现

     任何一个项目，那平台的代码都不可能没有一个BUG，尽管你的代码曾经被N次测试过，你的功能点被测了N次，所以某个项目会提过来一个BUG，

你现在开发的版本也许会有，你提供出去的版本也许也会有，所以你就会不定期的会修改一样的BUG在不同的项目里面。但是就算你修过，但是间隔如

果达2个星期，估计你这个BUG也会忘记怎么去改，还的从头去改，头大呀。

 

BUG特点四："修一个BUG，我改了3个项目" 开发版本与测试版本都的修改

    在修一个BUG的时候，修改正已经发布的版本，正在开发的版本，还有项目中出错的版本，天呀，就一个小小的BUG跑了我一天。

 

BUG特点五：“为了浮现这个BUG我花了一上午的时间” BUG浮现需要很长时间

  并不是所有的BUG会很快浮现，经常会听到一个同事在抱怨，天呀，这个BUG浮现花了我一上午时间。所以BUG的浮现会花很长时间。

 

BUG特点五："我讨厌你IE6"浏览器兼容是很大的一个BUG

   Js的兼容性，开发的版本至少兼容IE6+ie7.+ie8，我的机子上装的是IE8,测试的妹妹们是IE6，就算调BUG也的去同事机子上调，晕死了，趁人家中午

吃饭的时候去调兼容性问题，晕死了。

 

    小结：告诉你一个秘密呀，政府一般的项目都是IE6哦，这是秘密呀，千万别告诉别人。

所以经验告诉自己，做什么项目用什么浏览器。

 

BUG特点六：“紧急的，一般性，重要的”自己一定要分清哪些是重要的，只要修改了他，其他都可以迎刃而解

     BUG分重要的，一般性的，紧急的很让人恼火，3天之内必须解决，怎么公司还订了这个规矩。

 

BUG特点七：“这个问题他以前解决过，但是今天他没来”第二个人来解决这个同样的问题遇到的麻烦

      "这个问题呀，以前他解决过这个问题。","是呀, 那等他回来在修吧。“,"不行，的马上修"，晕死这么急呀。

 

BUG特点八：“在XP上有问题，win2003没问题”样式也的兼容操作系统呀？

      最让人头大的是，开发的部用的是2003，测试部是XP，JS弹出的框是不一样的不可以自适应窗口大小，晕死，怎么跟操作系统还有关系？

 

BUG特点九：“这是BUG吗？真的这么修吗？我怎么感觉是需求变了？我在改需求？”

     有时候自己根本不知道什么是BUG，头让你怎么就怎么，最讨厌这种感觉。。。。。

 

相信，各个公司都有自己BUG的管理方案，不管你是拿嗓子喊，还是我不知道的（也会很棒的方案）等等，下面是自己认为以些好的建议，也许不是

很全，但是我希望对BUG的管理有点好处吧，嘻嘻。。。。。。

 

解决方案

 

方案一：“不择手段的找到你系统里面的BUG，你会像测试人员那样去干吗？测试部是必须存在的”

 

”一个人写，2个人测“，不管怎么说测试部是有必要存在的，他们也许不是客户，但是他们的想法肯定跟一个程序员绝对是不一样的。

小结：最近一直在想一个问题，程序员去测试可以吗？不可以，比如一个最简单的添加方法，他只会去试最可以添加成功的方法，而不是像测试那样，

不择手段的找到你系统里面的BUG

 

方案二：“解决BUG花费了我们多少时间你算过吗”你绝对不可能在一天之内告诉我这个BUG已经OK了。。。。。。以为这个BUG OK还是不OK 是客户

说的算，而不是你。。。。。。

 

“BUG浮现”+“BUG修改”+“BUG复测”+“修改同样的BUG”+“。。。。。”+“BUG解决方案的提出”这个时间并不短，甚至比开发的时间还长，

但是你试图给一个方案去管理BUG的一生吗？

 

  小结：如果只是为了解决问题而解决问题，如果只是为了应付谁而去解决他，你怎么会知道其中乐趣呢？你怎么会给他那么长时间去解决问题呢？

 

方案三：“为一个BUG做方案,程序能改变你的工作方式”

    样式在“在XP上有问题，win2003没问题”，主要是用JS弹出的子页面不可以自适应所有才注意系统，然后去统计，用JS，记得当时统计客户的参

数有：系统是什么？IE是什么？IE安全加进去了吗？系统皮肤是什么？系统的补丁是什么？就是不断的调JS直到系统可以自适应。

 

小结：统计画了我很长时间，主要我对测试部的人不熟，后来头18提醒，写方案让测试部统计下吧，记得自己就改了下JS的相关参数，就一个自适

应的测试DEMO就OK了，虽然这件事情过了很长时间，但是还是记得当时自己那种很浮躁的感觉，真的很有感触“程序能改变你的工作方式”

 

 

方案四：“当项目开发完之后，在开发新模块的时候你留给你手下多长时间去修改BUG与开发新模块？”

   一个新的模块做完之后，一个有经验的领导者会给自己的手下二分之一的时间去修自己的BUG，另一半时间是去做新的模块，随着时间的BUG的

减少，给的时间会越来越少。但是也有些变态的领导者，会把你直接扔到下个项目，以前做的那个项目要不BUG连天，要不摇摇欲坠。

 

小结：一个模块出来，你的头没给你任何时间直接投入到下个项目的大有人在，这种现象会让你的项目越做越烂，因为不是所有的人会花10个小时

去干8个小时去干的事情。也就是说花10个小时去那8个小时的工资。

 

 

方案五：“任何一个东西不是你做的多大，而是你细节处理的有多好，你做的有多精致”

   一个脸很精致的女孩，可是你突然在脸上给包个包，你忍心吗？

 

小结：任何一个BUG，会让你的用户很不爽，试想想你的用户拿到你的项目是满面的补丁，就连页面的图片路径都是错的，那就是个午夜出来的

僵尸，恐怖而恶心，我很讨厌这种让人反胃的东西，任何一个东西不是你做的多大，而是你细节处理的有多好，你做的有多精致。

一个想把项目做好的企业，他会在乎任何细节，他会永远站在客户的角度去想问题，而不是一个程序员的角度，一个项目经理的角度，因为他

们深深的知道，客户会在乎这一像素。

 

方案六：“经常出现的BUG你试图去总结了吗？”

  以前遇到一个BUG，就是点击添加的时候，页面整个TABLE会颤抖一下，很郁闷的一件事情，其实就是细节的问题，但是没注意在

很多页面出现这个问题。

 

 

方案七：“这些BUG你想过如何彻底解决了吗”

  记得上次在动态创建消息表的表结构的时候缺2个字段，直接做法是打开库添加2个字段，系统表是系统跑的时候创建的，根本没彻

底解决这个问题呀。

 

小结：很多问题我们有时候只是解决了表面现象，其实也许我们一行简单的代码也许就可以彻底解决问题

 

方案八：“修改BUG的时候你去做记录了吗”

     你确定你在修的BUG不会带来新的BUG吗？那么最好记录下你都修改那个页面，同事以后出现同样的问题你需要在把他出来接着，

这样可以事半功倍。

 

小结：修完一个BUG之后，自己修改了什么，如果有BUG评论以及备注的话，最好写上面备注一下，如果没有备注工具的话，自己也要

写到记事本上哦，不用到还可以，用到的时候，你头大，主要记录下你改了那个文件，以及那个是什么问题等等尽可能让自己知道自己

改了什么。

 

方案九：“你有BUG库吗？是否有有一个系统在专门维护你项目里的BUG”

   “当我修改一个BUG的时候，需要记录一些信息，并且可以让很多人同步看到我修改这个BUG，并且可以参照这个问题去改现在出现

同样的BUG”一个公司人员会流动，并且不可能24小时在位，一个比较好的公司也会有bug系统，当一些BUG被解决之后，会被记录，

会成为后人的一些提示，尤其是对与平台这样的项目开发，这些BUG是项目的软穴，切也应该是有密级的。

 

小结：其实我认为一个有自己企业文化，一个靠软件吃饭的公司，必须有自己的这么一个BUG管理系统。曾经在网站上看到这样的系

统，但是这个东西竟然扔到网上了，对自己公司的产品是很不负责的，危险呀。

 

“BUG也是一种企业文化”

     一个以产品为生的企业，项目本身是企业的命脉，项目里面产生的BUG本身就是企业的一种文化，一种被遗忘的文化，这些BUG 

是什么？她的存在是证明你的软件更强大，证明你的项目在成长，证明一个很有耐心的人在维护她，捍卫她。

 

既然BUG那么重要，那么程序员， 那就拼命的修吧，呵呵，一下是自己总结的修BUG思路

那么如何去修BUG呢?

1.“给BUG定位”

  重要的？不重要的?大概可以BUG在那个位置，一定要看清到底是什么错，提示一定要看清，不会是需求的错吧？

2.看BUG是否以前解决过？是否是业务的问题？自己以前是否遇到过？是否已经记录过？跟据自己经验来判读这是个什么样的BUG? 

可以看看别的版本是否有同样的问题？

3."跟代码"，如果你很熟悉一般可以一下定位到那错了，如果不知道可以使用调试工具进行调试

 了解一些基本的调试，包括JS以及代码的调试

4.”一定要记录“，以备自己以后查找用

    记录bug描述，修改路径，那的文件

5.直接找测试人员进行测试到位

   如果系统有多个版本，也全部进行更新，根据你上面的记录文件进行修改即可，但是前提是你的代码已经测试过，并且是准确无误的

，自己需要测试下是否更新对，然后扔给测试人员去改

 

总结：不择手段的解决掉这个BUG，这才是硬道理。

     wow,终于完了，以上只是自己在修BUG的一点点感触，写下来纪念下自己曾经修改过的BUG，因为她们让我发现修BUG多了，会让你不经

意的喜欢上修BUG的感觉，那种为了找到错误点，不择手段的感觉。

   当然，以上只是自己做为一个程序员，在做这件事情的一些感触，关于BUG的管理，我提了很多建议，希望对大家有用,如果大家有好的建议

可以留言，嘻嘻，谢谢。