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

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

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

要多少時間才能修復bug，事先是很難知道的，特別是如果你和這些代碼還素不相識的話，情況就更加撲朔迷離了。要想修復問題得先知道問題的所在，而我們之所以無法準確估計時間是因為我們不知道需要多久才能發現癥結的所在，只有清楚這一點，我們才能合理估計修復 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 還會出現在哪里？如果一個 bug 需要耗費你很多時間，那么一定要好好弄清楚原因。此外，還需要思考的是，怎么做才能吸取經驗教訓，將來在類似的問題上不再栽跟頭？以及，我們采用的方法、使用的工具是否還有可以改進的地方？以及這些 bug 的影響和嚴重程度。

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

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

大部分的軟件漏洞的來源在哪里？分析師認為，相較于修復，發現 bug（包括理解 bug 和重現 bug）所需時間更長。有研究表明，大多數的 bug（差不多有3/4）既易于發現又易于修復：5天或許更少（這是基于大規模實時系統通過重量級 SDLC、大量審查和測試得出的數據）。但是也有很惡心的bug，即便你可以輕輕松松揪到它，還是還得“嘔心瀝血”才能修復好。

所以如果你打賭說你能很快修復bug，大多數情況下你還真沒說錯。不過當你打賭輸了的時候，那么，嘿嘿，就意味著你有煩惱了。所以，下次，boss再問什么時候能修復bug，別再傻乎乎地回答“馬上就能搞定”了。

河南億恩科技股份有限公司(www.artduck.net)始創于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網站建設、網站托管等網絡基礎服務，另有網總管、名片俠網絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900