什么是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 個不安全的使用方式。因此，不要”拿起來就用“，而要”三思而后行“。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
