写给我的团队成员（一）——什么是BUG？

      我知道你们都很忙。忙得连给代码写注释的时间都没有，哪有时间做总结呢？还是我来替大家做一些总结吧。我最近会找时间写一系列的短文，在email给你们的同时会发送到你们常去的JavaEye上。如果你抽空看看，对你和我们团队都有好处。今天我写了第一篇。

 

写给我的团队成员（一）—— 什么是BUG？

 

      什么是BUG？每个写过代码或者使用过软件的人似乎都知道它是什么。然而，我们的很多工作年限有限的开发人员总是简单认为：程序跑通了，自己测了N遍了就很少有BUG了。这是个危险的观念，没有理解深刻这一点的人会在自己的进步过中走很多弯路。更会给产品和团队带来各种大大小小的危机。

 

      对抗BUG是我们程序员永恒的主题，要在这场战斗中获胜，首先要做到“知己知彼”——什么是BUG?

 

      现在，我们来一起把BUG分为以下几个种类，你在Coding的时候要随时随地的想到这些：

 

• 最最普通的BUG。 我实在缺乏用语言来给这类BUG下定义的能力，因此你现在能够识别，这就是BUG的东西，应该可以归属于这一类。
  

• 编译不通过。 你可以认为这是最简单的BUG，根本不需要特别考虑，如果编译不过，Eclipse会在设计时给你个红XX 来提示的。但是，在下面的情况中，你可能看不到红XX，但BUG依然存在。

1. spring的xml。缺省的eclipse可不会在design time时给任何检查。你写错一个字母，都会让你无法运行。跟业务逻辑相关的依赖关系，更别指望eclipse替你找出来。
2. jsp中引用的java代码。不用我解释了吧，大家可能都有体验。至少我目前还没找到完全可靠的jsp plugin 可以帮助 eclipse来随时随地找出jsp中的代码错误。（除非你把上千个jsp文件都关闭并重新打开一遍）。

• 业务逻辑实现错误。 这就不需要过多赘述了。地球人都知道。

• 缺乏必要的事务。 在99.9%的“开发时”，事务不是必须的。在仅挨着的两条insert语句执行的瞬间，出现系统失效的可能性微乎其微。然而，一旦进入了生产环境，用“事务”来保持你要进行的这个action的完整性就显得非常重要了。当然，并不是所有的业务逻辑步骤都需要用事务来保护，况且让容器帮你你管理事务也是一种懒惰但有效的做法，但与此同时自己去考虑一下“这里如果没有事务，我是否安全？“的问题，对你的进步更有好处。

• 团队使用的基本库出错。 不要认为团队自己开发的基本类库是100%正确的，轻信不完善的API的思想是大量顽固BUG的藏身之处。团队自己生产的代码还在不断的完善和发展，毕竟咱们积累的这些”精华“与外面OpenSource的东西（而他们同样有BUG）相比，还差懂得远呢。我丝毫不怀疑里面存在超过100个算法缺陷和200个不安全的使用方式。因此，不要”拿起来就用“，而要”三思而后行“。

• 性能陷阱。 为了尽快实现业务逻辑。我们在第一次编码的时候往往不先考虑性能问题。这个想法不算太错误，但这个想法不能太过分。特别是涉及到一些”性能敏感”的代码段，比如我们产品中多处涉及到的Tcp Server的内核。这些部件的代码1天可能遭受几百万次的访问，瞬时绝对并发100是最正常的情况。因此0.1秒的性能损失，也会带来100x0.1=10秒的性能损耗。10秒，足以使一个TCP Server达到实际“不可用”的严重程度！10行马虎的代码，可能毁掉客户对我们团队辛苦生产的100万代码的信任。切记！切记！

• 安全隐患。 某些安全隐患在我们刚开始写实验性的代码时往往可以忽略，但绝不能忘记。你必须在这个产品进入到下一阶段的时候加上必要的安全检查代码和与安全相关的逻辑验证代码。回忆一下，你是否忽略了下面的工作：

1. http session检查。 尽管我们可以用框架来保证这一点。但你还是要检视一下，是否在某些功能的实现上，你确实忘记它了。
2. 参数类型校验。 当你把一个'a'传递到servlet用Internet.parse（）来处理的时候，你是否考虑了可能出现的异常情况。等等此类。
3. NullException。 特别注意，千万不要让NullException出现在jsp中，否则你很难在系统部署后排查错误。在你第一次编写jsp代码时，你就必须考虑你所使用的对象或者属性是否可能为Null。
4. Anti-flood。 最容易被初级程序员忽略的要点之一。因为这个bug永远不会出现在你的eclipse开发运行环境里。也往往被功能测试组的人忽略。但一旦存在这个隐患，一个最菜的Hacker用最普通的teardrop也会让你tear drop。

• 线程安全。 永远不要忘记，你的代码需要在一个多线程的环境中运行，随时随地都有可能出现并发的情况。你的产生的临时文件名是否用uuid来避免重名了？你的静态（或单态）变量是否线程安全。你是否忘记将spring里定义的bean设置为scope=prototype？

• 忘记删除临时文件。 在上传文件、生成验证图片、生成缩略图的时候，你都可能用到临时文件。你是否在使用完毕后及时的删除了它？你是否考虑过在发生异常后，仍然安全的删除了这个文件？特别需要指出的是，我们在编码阶段的测试时，很难发现遗漏临时文件清理的工作。单在系统上线运行后，大量滞留在目录下的过期临时文件将用光客户的服务器磁盘空间，降低系统IO的性能。

• 极不友好的UI操作。 极不友好的UI操作同样是严重的BUG。比如：

1. 当用户提交表单的时候可能填写了错误格式的信息，而你的程序再提示错误，重新显示表单的时候清除了用户已经填写的数据。这对你的软件的使用者来说是极其恼火的体验，对于创造这个代码的您来说则是一种耻辱。
2. 另一种“极不友好的UI操作“可能发生在这种情况——你必须跟测试人员解释——他体验到这次系统出错的原因是他（测试人员）操作的步骤或顺序不正确。天那，这是噩梦，不仅是用户的噩梦，也是你的噩梦。如果你坚持你的做法没错，我将决定在系统上线后，把你的手机和家里的电话号码做为HELP放在你创造的界面的显著位置呈现给使用它的80万用户。

 

......

 

儿子刚刚给我倒了杯咖啡端倒了书房里，从味道上判断，他在厨房里误把味精当白糖给我放了很多。但无论如何他是在讨好我去陪他玩了。那么，这次就写到这里吧。

 

评论

46 楼 yimlin 2009-06-01  

靠计划，检查列表来贯彻是不靠谱的：
1.执行成本太高，也面临着计划时间的上风险；
2.最重要的是无法验收，你无法知道项目组成员是否贯彻了所有的检查，现有代码是否消除检查列表中的问题。

于是你只能执行警察权，偶尔抽查下，一旦发现则严惩不殆；但是bug已经产生了，修改bug本身带了相应的成本，甚至影响了计划。更进一步，你无法确认系统是否还有其它应检查而未发现的bug。

可能的有效方案：
1.框架完成必要的检查、以及修复（回收资源）工作；
2.通过checkstyle等工具检查提交的代码；
3.持续集成尽早的发现问题，争取时间；

45 楼 ylz4647 2009-05-21  

<p>感触良多，做一个IT人员真不容易</p>

44 楼 jhlcss 2008-12-05  

<div class='quote_title'>ftw118 写道</div>
<div class='quote_div'>
<div class='quote_title'>neora 写道</div>
<div class='quote_div'><br/>个人认为计划不是关键问题，<strong>关键是你的计划中是否包含了计划了变化。</strong></div>
<p> </p>
<p>    严重同意。</p>
</div>
<p><br/>在这里我觉得计划定了，也定了可能的计划变更，也要考虑风险，制定风险规避措施。</p>
<p>更重要的是计划执行和跟踪。</p>

43 楼 andy54321 2008-11-25  

还是要测试；
自己的代码看百遍还是没错。

42 楼 yinxiangjake 2008-11-17  

继续关注中

41 楼 oyl822 2008-10-22  

楼主是个很幽默的人哦。

40 楼 35687638 2008-10-22  

关注，关注。。。

39 楼 lovinchan 2008-10-15  

    我觉得这个方面有个意识的问题，当时没找出bug是很正常的，不过在工作的过程中，难免会有运行不顺畅的时候，这时候有意识的人应该就会想这个是什么原因了。这个我觉得也可以说是一种经过锻炼后的一种能力吧。

38 楼 laodizhuq 2008-10-15  

画蛇添足的异常捕捉。
有些同事会在他的方法中捕捉异常，然后又不打印异常日志(而是直接System.out.println(e))，也不重新抛出。
结果导致产品上线后，发生莫名其妙的错误，而找不到原因。

37 楼 zcjava 2008-10-14  

哈哈 同意   计划永远没有变化快啊。  要实时的调整

36 楼 fantasy 2008-10-08  

你这说的不应该是BUG，应该是代码质量。

35 楼 healthlin 2008-10-08  

bug很多的时候，对于scm的管理要求就非常高，还有回归测试，出现的bug不能再次出现，也尽量避免1个bug导致了另外的bug产生。

在设计代码前，对业务逻辑和产品需求，需要调研的非常透彻，程序自己产生的bug是可以解决的，一旦需求或者和用户沟通不够，产生的”bug“，那是无穷尽的

34 楼 ironurbane 2008-10-06  

那些中间件的BUG算么
我曾经遇到一个问题，是WEBLOGIC 服务器，同样一个请求路径aa.do?在XP下通过，可以获得自己想要的结果，而在2000下没有反映，或者是没有得到自己想要的结果。这个问题曾经让我头疼两个晚上，幸好最后搞定了，
象这样的BUG真的很难去定位》

33 楼 zds625 2008-09-28  

恩，受教了，发觉在开发过程中也经常会有这些问题~！

32 楼 pekkle 2008-09-24  

什么文档啊，规划啊，都是假的。
关键是一个执行力度，计划赶不上变化

31 楼 alfred.w 2008-09-24  

楼主混淆了一些问题，我想，

引用

    * 编译不通过。 你可以认为这是最简单的BUG，根本不需要特别考虑，如果编译不过，Eclipse会在设计时给你个红XX 来提示的。但是，在下面的情况中，你可能看不到红XX，但BUG依然存在。

       1. spring的xml。缺省的eclipse可不会在design time时给任何检查。你写错一个字母，都会让你无法运行。跟业务逻辑相关的依赖关系，更别指望eclipse替你找出来。
       2. jsp中引用的java代码。不用我解释了吧，大家可能都有体验。至少我目前还没找到完全可靠的jsp plugin 可以帮助 eclipse来随时随地找出jsp中的代码错误。（除非你把上千个jsp文件都关闭并重新打开一遍）。

编译不通过是否是bug，我持保留意见。关于jsp中引用的java代码，如果是n年前的遗留项目就算了，不太老的项目我觉得是不是考虑换freemarker或者其他的，而且有不少插件可以做语法判断。表现层只应该做表现层的事情。

引用

性能陷阱。

请参看一下《重构》一书，请问系统上线以前是不是需要压力，性能测试呢？非要等着客户去发现？

引用

极不友好的UI操作。

请问UI设计是谁来做的呢，设计完不需要审核么？

30 楼 cuiyi.crazy 2008-09-20  

pipilu 写道

我很想知道怎么避免写程序中bug太多。
我感觉我写的程序bug还是多了些，而且我写的时候其实很注意，经常重构代码，避免重复的逻辑在多处实现，避免拷贝粘贴。
你们有过类似的困扰么？是怎么减少bug数的。

如果你真的是这么想的，如下的路你可以尝试：
不要一直做新东西；
到这样的软件公司去尝试一年左右：
1） 规模不是很大，可以让你维护改进系统的大部分
2） 是一个遗留项目

我想一年下来后，你就会对如何减少bug，如何减少无视性能，如何发现你意识不到的地方，有很大的帮助的；

而这，又很需要你静下心来做。

29 楼 wjs0702cn 2008-09-19  

我想拜你为师

28 楼 pipilu 2008-09-19  

我很想知道怎么避免写程序中bug太多。
我感觉我写的程序bug还是多了些，而且我写的时候其实很注意，经常重构代码，避免重复的逻辑在多处实现，避免拷贝粘贴。
你们有过类似的困扰么？是怎么减少bug数的。

27 楼 miaomiao0307 2008-09-19  

从bug中吸取经验，减少bug