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

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

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

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

“發(fā)現(xiàn)缺陷—理解缺陷—通常占了工作的90%”。

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

查找和修復

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

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

發(fā)現(xiàn)和修復需要多久

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

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

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

原文：Fixing a Bug is Like Catching a Fish