四個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總會有的，麪包也總會有的。