寫給我的團(tuán)隊成員(一)什么是BUG?
我知道你們都很忙。忙得連給代碼寫注釋的時間都沒有，哪有時間做總結(jié)呢?還是我來替大家做一些總結(jié)吧。我最近會找時間寫一系列的短文，在email給你們的同時會發(fā)送到你們常去的JavaEye上。如果你抽空看看，對你和我們團(tuán)隊都有好處。今天我寫了***篇。
寫給我的團(tuán)隊成員(一)—— 什么是BUG?
什么是BUG?每個寫過代碼或者使用過軟件的人似乎都知道它是什么。然而，我們的很多工作年限有限的開發(fā)人員總是簡單認(rèn)為：程序跑通了，自己測了N遍了就很少有BUG了。這是個危險的觀念，沒有理解深刻這一點的人會在自己的進(jìn)步過中走很多彎路。更會給產(chǎn)品和團(tuán)隊帶來各種大大小小的危機(jī)。
對抗BUG是我們程序員永恒的主題，要在這場戰(zhàn)斗中獲勝，首先要做到“知己知彼”——什么是BUG?
現(xiàn)在，我們來一起把BUG分為以下幾個種類，你在Coding的時候要隨時隨地的想到這些：
最最普通的BUG。 我實在缺乏用語言來給這類BUG下定義的能力，因此你現(xiàn)在能夠識別，這就是BUG的東西，應(yīng)該可以歸屬于這一類。
編譯不通過。 你可以認(rèn)為這是最簡單的BUG，根本不需要特別考慮，如果編譯不過，Eclipse會在設(shè)計時給你個紅XX 來提示的。但是，在下面的情況中，你可能看不到紅XX，但BUG依然存在。
spring的xml。缺省的eclipse可不會在design time時給任何檢查。你寫錯一個字母，都會讓你無法運行。跟業(yè)務(wù)邏輯相關(guān)的依賴關(guān)系，更別指望eclipse替你找出來。
jsp中引用的java代碼。不用我解釋了吧，大家可能都有體驗。至少我目前還沒找到完全可靠的jsp plugin 可以幫助 eclipse來隨時隨地找出jsp中的代碼錯誤。(除非你把上千個jsp文件都關(guān)閉并重新打開一遍)。
業(yè)務(wù)邏輯實現(xiàn)錯誤。 這就不需要過多贅述了。地球人都知道。
缺乏必要的事務(wù)。 在99.9%的“開發(fā)時”，事務(wù)不是必須的。在僅挨著的兩條insert語句執(zhí)行的瞬間，出現(xiàn)系統(tǒng)失效的可能性微乎其微。然而，一旦進(jìn)入了生產(chǎn)環(huán)境，用“事務(wù)”來保持你要進(jìn)行的這個action的完整性就顯得非常重要了。當(dāng)然，并不是所有的業(yè)務(wù)邏輯步驟都需要用事務(wù)來保護(hù)，況且讓容器幫你你管理事務(wù)也是一種懶惰但有效的做法，但與此同時自己去考慮一下“這里如果沒有事務(wù)，我是否安全?“的問題，對你的進(jìn)步更有好處。
團(tuán)隊使用的基本庫出錯。 不要認(rèn)為團(tuán)隊自己開發(fā)的基本類庫是100%正確的，輕信不完善的API的思想是大量頑固BUG的藏身之處。團(tuán)隊自己生產(chǎn)的代碼還在不斷的完善和發(fā)展，畢竟咱們積累的這些”精華“與外面OpenSource的東西(而他們同樣有BUG)相比，還差懂得遠(yuǎn)呢。我絲毫不懷疑里面存在超過100個算法缺陷和200個不安全的使用方式。因此，不要”拿起來就用“，而要”三思而后行“。
性能陷阱。 為了盡快實現(xiàn)業(yè)務(wù)邏輯。我們在***次編碼的時候往往不先考慮性能問題。這個想法不算太錯誤，但這個想法不能太過分。特別是涉及到一些”性能敏感”的代碼段，比如我們產(chǎn)品中多處涉及到的Tcp Server的內(nèi)核。這些部件的代碼1天可能遭受幾百萬次的訪問，瞬時絕對并發(fā)100是最正常的情況。因此0.1秒的性能損失，也會帶來100x0.1=10秒的性能損耗。10秒，足以使一個TCP Server達(dá)到實際“不可用”的嚴(yán)重程度!10行馬虎的代碼，可能毀掉客戶對我們團(tuán)隊辛苦生產(chǎn)的100萬代碼的信任。切記!切記!
安全隱患。 某些安全隱患在我們剛開始寫實驗性的代碼時往往可以忽略，但絕不能忘記。你必須在這個產(chǎn)品進(jìn)入到下一階段的時候加上必要的安全檢查代碼和與安全相關(guān)的邏輯驗證代碼?；貞浺幌?，你是否忽略了下面的工作：
http session檢查。 盡管我們可以用框架來保證這一點。但你還是要檢視一下，是否在某些功能的實現(xiàn)上，你確實忘記它了。
參數(shù)類型校驗。 當(dāng)你把一個'a'傳遞到servlet用Internet.parse()來處理的時候，你是否考慮了可能出現(xiàn)的異常情況。等等此類。
NullException。 特別注意，千萬不要讓NullException出現(xiàn)在jsp中，否則你很難在系統(tǒng)部署后排查錯誤。在你***次編寫jsp代碼時，你就必須考慮你所使用的對象或者屬性是否可能為Null。
Anti-flood。 最容易被初級程序員忽略的要點之一。因為這個bug永遠(yuǎn)不會出現(xiàn)在你的eclipse開發(fā)運行環(huán)境里。也往往被功能測試組的人忽略。但一旦存在這個隱患，一個最菜的Hacker用最普通的teardrop也會讓你tear drop。
線程安全。 永遠(yuǎn)不要忘記，你的代碼需要在一個多線程的環(huán)境中運行，隨時隨地都有可能出現(xiàn)并發(fā)的情況。你的產(chǎn)生的臨時文件名是否用uuid來避免重名了?你的靜態(tài)(或單態(tài))變量是否線程安全。你是否忘記將spring里定義的bean設(shè)置為scope=prototype?
忘記刪除臨時文件。 在上傳文件、生成驗證圖片、生成縮略圖的時候，你都可能用到臨時文件。你是否在使用完畢后及時的刪除了它?你是否考慮過在發(fā)生異常后，仍然安全的刪除了這個文件?特別需要指出的是，我們在編碼階段的測試時，很難發(fā)現(xiàn)遺漏臨時文件清理的工作。單在系統(tǒng)上線運行后，大量滯留在目錄下的過期臨時文件將用光客戶的服務(wù)器磁盤空間，降低系統(tǒng)IO的性能。
極不友好的UI操作。 極不友好的UI操作同樣是嚴(yán)重的BUG。比如：
當(dāng)用戶提交表單的時候可能填寫了錯誤格式的信息，而你的程序再提示錯誤，重新顯示表單的時候清除了用戶已經(jīng)填寫的數(shù)據(jù)。這對你的軟件的使用者來說是極其惱火的體驗，對于創(chuàng)造這個代碼的您來說則是一種恥辱。
另一種“極不友好的UI操作“可能發(fā)生在這種情況——你必須跟測試人員解釋——他體驗到這次系統(tǒng)出錯的原因是他(測試人員)操作的步驟或順序不正確。天那，這是噩夢，不僅是用戶的噩夢，也是你的噩夢。如果你堅持你的做法沒錯，我將決定在系統(tǒng)上線后，把你的手機(jī)和家里的電話號碼做為HELP放在你創(chuàng)造的界面的顯著位置呈現(xiàn)給使用它的80萬用戶。
【編輯推薦】
