寫給我的團隊成員（一）——什麼是BUG？

導讀：
　　相關文章:
　　Web Services開發體會和項目教訓
　　最後，說破了SOA精髓的還是中國人
　　吹彈得破是重回一人犯錯，全家光榮的老路
　　推薦圈子: 金蝶AOM框架
　　更多相關推薦
　　我知道你們都很忙。忙得連給代碼寫註釋的時間都沒有，哪有時間做總結呢？還是我來替大家做一些總結吧。我最近會找時間寫一系列的短文，在email給你們的同時會發送到你們常去的JavaEye上。如果你抽空看看，對你和我們團隊都有好處。今天我寫了第一篇。
　　
　　寫給我的團隊成員（一）—— 什麼是BUG？
　　
　　什麼是BUG？每個寫過代碼或者使用過軟件的人似乎都知道它是什麼。然而，我們的很多工作年限有限的開發人員總是簡單認爲：程序跑通了，自己測了N遍了就很少有BUG了。這是個危險的觀念，沒有理解深刻這一點的人會在自己的進步過中走很多彎路。更會給產品和團隊帶來各種大大小小的危機。
　　
　　對抗BUG是我們程序員永恆的主題，要在這場戰鬥中獲勝，首先要做到“知己知彼”——什麼是BUG?
　　
　　現在，我們來一起把BUG分爲以下幾個種類，你在Coding的時候要隨時隨地的想到這些：
　　
　　最最普通的BUG。我實在缺乏用語言來給這類BUG下定義的能力，因此你現在能夠識別，這就是BUG的東西，應該可以歸屬於這一類。
　　編譯不通過。你可以認爲這是最簡單的BUG，根本不需要特別考慮，如果編譯不過，Eclipse會在設計時給你個紅XX來提示的。但是，在下面的情況中，你可能看不到紅XX，但BUG依然存在。
　　spring的xml。缺省的eclipse可不會在design time時給任何檢查。你寫錯一個字母，都會讓你無法運行。跟業務邏輯相關的依賴關係，更別指望eclipse替你找出來。
　　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萬代碼的信任。切記！切記！
　　安全隱患。某些安全隱患在我們剛開始寫實驗性的代碼時往往可以忽略，但絕不能忘記。你必須在這個產品進入到下一階段的時候加上必要的安全檢查代碼和與安全相關的邏輯驗證代碼。回憶一下，你是否忽略了下面的工作：
　　http session檢查。儘管我們可以用框架來保證這一點。但你還是要檢視一下，是否在某些功能的實現上，你確實忘記它了。
　　參數類型校驗。當你把一個'a'傳遞到servlet用Internet.parse（）來處理的時候，你是否考慮了可能出現的異常情況。等等此類。
　　NullException。特別注意，千萬不要讓NullException出現在jsp中，否則你很難在系統部署後排查錯誤。在你第一次編寫jsp代碼時，你就必須考慮你所使用的對象或者屬性是否可能爲Null。
　　Anti-flood。最容易被初級程序員忽略的要點之一。因爲這個bug永遠不會出現在你的eclipse開發運行環境裏。也往往被功能測試組的人忽略。但一旦存在這個隱患，一個最菜的Hacker用最普通的teardrop也會讓你tear drop。
　　線程安全。永遠不要忘記，你的代碼需要在一個多線程的環境中運行，隨時隨地都有可能出現併發的情況。你的產生的臨時文件名是否用uuid來避免重名了？你的靜態（或單態）變量是否線程安全。你是否忘記將spring裏定義的bean設置爲scope=prototype？
　　忘記刪除臨時文件。在上傳文件、生成驗證圖片、生成縮略圖的時候，你都可能用到臨時文件。你是否在使用完畢後及時的刪除了它？你是否考慮過在發生異常後，仍然安全的刪除了這個文件？特別需要指出的是，我們在編碼階段的測試時，很難發現遺漏臨時文件清理的工作。單在系統上線運行後，大量滯留在目錄下的過期臨時文件將用光客戶的服務器磁盤空間，降低系統IO的性能。
　　極不友好的UI操作。極不友好的UI操作同樣是嚴重的BUG。比如：
　　當用戶提交表單的時候可能填寫了錯誤格式的信息，而你的程序再提示錯誤，重新顯示錶單的時候清除了用戶已經填寫的數據。這對你的軟件的使用者來說是極其惱火的體驗，對於創造這個代碼的您來說則是一種恥辱。
　　另一種“極不友好的UI操作“可能發生在這種情況——你必須跟測試人員解釋——他體驗到這次系統出錯的原因是他（測試人員）操作的步驟或順序不正確。天那，這是噩夢，不僅是用戶的噩夢，也是你的噩夢。如果你堅持你的做法沒錯，我將決定在系統上線後，把你的手機和家裏的電話號碼做爲HELP放在你創造的界面的顯著位置呈現給使用它的80萬用戶。
　　
　　......
　　
　　兒子剛剛給我倒了杯咖啡端倒了書房裏，從味道上判斷，他在廚房裏誤把味精當白糖給我放了很多。但無論如何他是在討好我去陪他玩了。那麼，這次就寫到這裏吧。
　　
　　聲明：JavaEye文章版權屬於作者，受法律保護。沒有作者書面許可不得轉載。
　　推薦鏈接
　　輝煌盛會-微軟WinHec 2008 邀您共赴卓越！
　　在繁瑣中掙扎還是簡化自主管理？
　　IBM Rational軟件開發高峯論壇9月揭幕

本文轉自
http://www.javaeye.com/topic/241569