英文原文：Fixing a Bug is Like Catching a Fish

經理：該Bug何時能得到修復？

經驗缺乏的程序員：也許一個小時？最多兩個小時！馬上去做！

經驗豐富的程序員：嗯，捉一條魚需要多少時間呢？

　　在現實操作中，很難能明確知道一個軟件缺陷需要多久可以修復，尤其是當你對代碼不了解的情況下。James Shore在“敏捷開發藝術”一書中指出：“在你需要修復Bug時，你必須找到是哪里出錯了？”，問題的關鍵是不能準確估算多久才能找出是哪里報錯的。只有知道“病源”在哪？你才能準確估算修復的時間。但那為時已晚，根據Steve McConnell：

“發現缺陷——理解缺陷——通常占了工作的90%”。

　　有許多缺陷只需要改一行代碼就可以修復。時間都花在確定該行上面，就好像釣魚的時候該把魚鉤放哪？何時何地魚會上鉤一樣。每個Bug都有它們自己的性格特征，有些可能很容易被發現，而有些可能會跟你玩“捉迷藏”，并且容易發現的Bug不一定就很難修復，當然，那些擅長玩“隱藏”的Bug有可能很容易被修復。

　　查找和修復

　　下面讓我們來看看如何發現并修復Bug。當調試時，Paul Butcher把每個步驟都進行了很好的描述。經驗豐富的程序員會很熟悉這種結構化和紀律性的步驟要領。

1. 確定查找目標，審查Bug報告，看看該Bug描述是否很合理并且提供了足夠的信息去發現和重現。檢查一下該報告以前是否遇到過，如果是，可以檢查以前是如何處理的。
2. 清理桌面——找到正確的代碼并檢查、清理工作空間。
3. 設置與之匹配的測試環境。這可能是微不足道的，或者是不可能出現的，如果客戶是在一個你無法訪問的配置下運行。
4. 對代碼的理解已經毫無問題，并且通過現有的測試套件。
5. 釣魚的時間到了，重現并且診斷錯誤。如果你不能重現這個錯誤，那么就無法去修復。
6. 寫新的（失敗的）開發測試報告或者修復現有測試報告來捕捉Bug。
7. 進行修復——確定沒有破壞其他功能模塊。這里可能會包括，在修復之前對代碼進行重構使代碼更容易被理解，并且使整個修復更安全。在后面的回歸測試中確保沒有引入任何新的錯誤。
8. 努力讓代碼更安全，更清潔，做一些循序漸進的重構確保代碼更健壯并且易于維護的。
9. 修復完成后，讓他人進行審查，確保你沒有做一些愚蠢的事情。
10. 再次檢查。
11. 檢查該Bug在其他分支中是否存在，如果你不是主線，你可以在里面進行合并，然后在代碼里面進行處理，并且瀏覽所有相同的評論和測試報告。
12. 結束并且進行思考和總結。明白是哪里出錯了？為什么？是否真正理解自己的修復？在別的地方還會發現這個錯誤嗎？在Pragmatic Programmer，Andy Hunt和Dave Thomas也同樣問了這樣的問題：“如果你花了很長時間去修復這個Bug，問問自己，到底是為什么？”在將來，如何讓該Bug更容易被發現和修復？如何提高修復方法或許是使用工具？思考的是否深入，要看這個Bug影響和所花的時間有多長？

　　發現和修復需要多久

　　設置測試環境所需的時間，重現一個Bug或者修復可能遠遠超過在代碼中查找和修復的時間。但是對于那種小缺陷，在發現時即可修復。

　　在軟件開發中，關于大多數軟件缺陷來自哪里？Dewayne Perry解釋到：發現一個Bug（理解并重現Bug）比多久去修復更難。研究發現，大多數Bug（幾乎3/4）很容易被發現和理解，并且不會花多少時間去修復：5天或更少（這是在大型實時系統與一個重量級的SDLC中，經過大量檢查和測試發現的）。這里有一個長期隱藏型Bug，可能需要花更長的時間修復，即使這個Bug微不足道：

　　所以在你發現Bug的時候，可以和自己打賭，它很快就會被修復，這個命中率會很高。但是當打賭失敗時，你可能會錯很多，或者徹底來個大錯特錯。

it知識庫：修復Bug好比釣魚，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。