修復Bug好比釣魚

        原文：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 微不足道：

發現/修復工作	小于 5 天修復	大于 5 天
缺陷可以重現	72. 5%	18. 4%
很難或者不能重現	5. 9%	3. 2%

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