bug給你帶來的四個好處

“大多數開發人員只是想寫新的功能,他們不想使用維護和修補漏洞”。這也是大多數開發人員是錯過的樂趣和好處就是發現和修復bug。

每個錯誤都可以教你一些東西。

反饋是一個關鍵，它是敏捷開發的主要原則之一。單元測試和迭×××發技術更快地提供反饋。與單元測試你的代碼是否有效的問題上得到反饋,和每個交付版本你可以聽聽客戶認為的新特性。錯誤報告是另一種形式的反饋您的代碼。一個錯誤的可以有許多不同的原因。一些可能性是:一個簡單的編碼錯誤(比如一個嵌套的if語句,你最終在錯誤的分支),或者一個錯誤的假設你(也許傳入的消息并不總是有某些字段,所以你有一個空指針異常),或有缺失的要求(你應該回答消息以不同的方式,如果一個給定的參數存在),或客戶使用軟件在一個意外的(但正確),導致錯誤。

在這些情況下,您可以學習如何代碼,它是關于你的產品或系統的作用。例如,當我在Tilgin VoIP開發產品,有一個情況我們收到了一個錯誤的信息,導致我們的軟件循環下去。消息所包含元素使用tag-length-value編碼(電磁閥)參數,長度值元素的總長度。這樣你可以跳過未使用或未知元素向前跳“長度”的字節數。在這種情況下,長度值是零,所以跳過我們指向相同的元素后,指出在跳之前,導致無限循環。這個bug前,仔細檢查我的代碼長度值太大值會導致閱讀過去的消息緩沖區。不過,在那之前,我從來沒有想到,一個零長度可能是同樣糟糕。

自己的代碼變得更容易調試。

當你花時間故障問題和修復bug,它不會花很長時間,直到你想讓自己的代碼盡可能容易調試。這是令人沮喪的不所有可用的信息。一個非常常見的問題是不包括動態信息的異常。例如,假設有代碼,預計值范圍在0 – 20。有多少次你看到一個異常,只是說“非法價值”?不告訴你如果你想找到一個bug。如果例如21日收到,應該說“非法值:21日不在范圍0 – 20”。它有助于包括允許范圍,肯定有助于包括當前值。當前值可能是21日或-128年或65535年。所有這些可能給你一個線索是什么導致了它,你不從一個普通的“非法價值”。甚至Steve McConnell打破這個規則在某些地方的優秀作品代碼完成。例如,在第15章中有一個例子,一個意想不到的發現類型的字符,但錯誤消息不包括字符的問題。每次你找到并修復一個錯誤,你需要問問自己:我應該做有什么在我的代碼不同,以消除錯誤避免未來再次出錯嗎?有什么我應該做,使這種錯誤更容易避免發生在未來嗎?

你和客戶會很高興。

正如我所提到的,為什么我愛編碼、編程的樂趣之一就是做對別人有用的東西。你得到同樣的踢修復一個缺陷,但在不同的時間尺度。提供新功能通常需要一段時間,但一個bug修復可以在一個小時內完成。每個固定的錯誤讓你感覺你是完成一些東西,這是一個偉大的感覺。有點矛盾,修復一個缺陷會使客戶滿意。如果沒有一個錯誤首先,不會有需要修復它,那么為什么他們應該快樂嗎?然而,我的經驗是,他們樂于接受一個bug修復,尤其是如果它是快速解決。每個人都知道總是會有缺陷。重要的是,有人準備修復它們很快被發現時。

解決問題是有趣的。

許多程序員喜歡解決問題,像數學難題,編程挑戰,數獨或填字游戲。甚至謀殺謎團飼料解讀:你看看線索,試著找出它的發生而笑。調試和修復bug是相同的。每個錯誤都是一個新的謎題找出。經常看到一個新的錯誤報告的時候你的第一反應是:這是不可能的嗎?怎么能這樣呢?這是當你開始尋找線索。日志怎么說?從系統錯誤報告嗎?此時系統中發生了什么?最近任何改變——新軟件,配置更改,交通干擾?讓找出開始!這些都是四個原因我喜歡調試和修補漏洞太多。你的經驗是什么?

后記：月小升認為，正確的策略是沒次編寫一小段代碼，就多加測試，把bug消除在集成之前，越在前期檢測，越容易查到bug，而且后期調用無bug的模塊，團隊作業效率會高出很多。不過bug總會有的，面包也總會有的。

http://java-er.com/blog/4-bug-good/