修複bug的12個關鍵步驟

boss：那麼，你需要多長時間來修複這個bug？

沒有經驗的程式員：給我一個小時？最多兩個小時？我能馬上搞定它！

有經驗的程式員：這麼說吧，釣到一條魚要多久我就要多久？！

　　要多少時間才能修複bug，事先是很難知道的，特別是如果你和這些代碼還素不相識的話，情況就更加撲朔迷離了。James Shore在《The Art of Agile 》一書中，明確指出要想修複問題得Crowdsourced Security Testing道問題的所在。而我們之所以無法準確估計時間是因為我們不知道需要多久才能發現癥結的所在，只有清楚這一點，我們才能合理估計修複bug所需要花費的時間。不過，這個時候恐怕黃花菜都涼了。 Steve McConnell曾說過：

“發現問題—理解問題—這就是程式員90％的工作。”

　　很多bug都只需改動某一行代碼即可。但是需要投入大量時間的是，後面還得指出怎麼樣才是正確的——就像我們在釣魚的時候，得知道往哪裡下誘餌，什麼時候魚兒容易上鉤等等。話說bug有四種類型：第一種易尋易修複，第二種難尋易修複，第三種易尋難修複，第四種難尋難修複。最悲劇的就是最後一型的，不但“尋尋覓覓，淒淒涼涼戚戚”，哪怕終於千辛萬苦滴水穿石，也只能在那邊不由自主地抓耳撓腮，無奈歎一句“路漫漫其修遠兮”。可以這麼說，除非是新鮮出爐的代碼，不然讓你找bug就跟瞎子摸象一樣——糊裡糊塗，不知道歸屬於哪種bug類型。

　尋找和修複bug

　　你知道“尋找和修複bug”意味著什麼嗎？沒錯，就是調試！不斷的調試，無數次的調試！Paul Butcher通過大量工作，總結出以下結構化的步驟：

　　1.明確目的。仔細查閱異常報告，確定是否是個bug，找出各種有用的資訊發現問題的癥結，予以重現。再次檢查是否與報告發生重複。如果發生重複，那看看曾經的相關人員是如何處理的。

　　2.準備工作——找出正確的代碼，用排除法清理工作區域。

　　3.匹配測試環境。如果客戶正在操作電腦配置，那麼此過程可以跳躍。

　　4.明確代碼的用途，確保現有測試載入器一切正常。

　　5.好了，現在可以出發釣魚去咯——重現和診斷錯誤。如果你不能做到重現，那你就不能證明你已經完成修複工作。

　　6.編寫測試案例，或者通過現成的測試案例來捕獲bug。

　　7.進入修複模式——請務必確保不會影響到其他任何部分。但是，在開展修複工作之前，可能你還要包攬重構工作，因為只有這樣，你才能無所顧忌地搗鼓代碼。而且事後迴歸測試，還能確保你不會加入任何新的bug。

　　8.整理代碼。通過一步一步重構，讓你的代碼更易於理解，更安全。

　　9.找別人來審查一下，當局者迷旁觀者清。

　　10.再次檢查此修複過程。

　　11.試著不從主線出發，以檢查這些bug是否會影響其他支線。合并這些變化，處理代碼中的差異，回顧所有的審查和測試等工作。

　　12.思考。好好想一想哪裡錯了以及為什麼錯了？為什麼你的修複會起效？這種類型的bug還會出現在哪裡？在《 The Pragmatic Programmer》一書中，Andy Hunt 和Dave Thomas也如是指出“如果一個bug需要耗費你很多時間，那麼一定要好好弄清楚原因”。此外，還需要思考的是，怎麼做才能吸取經驗教訓，將來在類似的問題上不再栽跟頭？以及，我們採用的方法、使用的工具是否還有可以改進的地方？以及這些bug的影響和嚴重程度。

　找到bug，還是修複bug，哪個需要更多時間？

　　或許建立一個測試環境、重現問題和測試bug所需的時間，要遠遠多於找到bug和修複bug的時間。不過對於一小部分顯而易見的bug，找到它們很簡單——不過修複起來可能就不盡如人意了。

　　在《Making Software》一書中，有一章主要是探討“大部分的軟體漏洞的來源”，Dewayne Perry分析認為，相較於修複，發現bug（包括理解bug和重現bug）所需時間更長。有研究表明，大多數的bug（差不多有3/4）既易於發現又易於修複：5天或許更少（這是基於大規模即時系統通過重量級SDLC、大量審查和測試得出的資料）。但是也有很噁心的bug，即便你可以輕輕鬆鬆揪到它，還是還得“嘔心瀝血”才能修複好。

發現/修複 修複時間<=5天 修複時間>5天

能重現問題 72.5% 18.4%

難以重現或根本沒法重現 5.9% 3.2%

　　所以如果你打賭說你能很快修複bug，大多數情況下你還真沒說錯。不過當你打賭輸了的時候，那麼，嘿嘿，就意味著你有大麻煩了。

　　所以，下次，boss再問什麼時候能修複bug，別再傻乎乎地回答“馬上就能搞定”了。

