什么是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 个不安全的使用方式。因此，不要”拿起来就用“，而要”三思而后行“。
文章来源于领测软件测试网 https://www.ltesting.net/
