如何有效地解Bug (RED方法)

轉載請註明來源:http://blog.csdn.net/horkychen 

解bug應當是修複代碼中的缺陷，而不只是隱藏起來!

(譯註 ：解Bug時常發生分析時總感覺快找到答案了，而後面卻一再陷入僵局。比如，將線程同步問題引起的一些時而有，時而沒有的問題。分析時可能會認為這是個典型的線程同步問題，A線程沒有按照預期的方式改變某個變數，導致了B線程處理出錯。這樣的分析結果如果沒有調試(Debug)的支援，就有可能將開發人員帶入死胡同，找出一大堆的解決方案可能都無法完整地解掉Bug。一定要在每次陷入困境的時候，回頭想一想，還有沒有什麼被忽略了。在一開始就對問題進行充分的瞭解是十分必要的。下文中作者提供了一個簡單的流程可供參考。)

圖片來源:http://www.phptechie.com

原文:http://forums.mtgsalvation.com/blog.php?b=3108

過去兩年工作中，我竟然成了一個擅長解Bug的傢伙。真不知道為什麼偏偏是解Bug成了自然而然的事。在這段時間裡我總結出了一套解bug的流程，簡稱為RED方法吧(譯註:感 覺可以像是紅色警戒!)。不過，這也不是什麼新的方法論了。事實上，它成為標準的軟體開發實踐已經有些年頭了。但是我依然見到許多開發人員無法系統運用這個方法，總是被解Bug弄得頭大。這就是寫這篇文章的原因。

RED方法是什嗎？它其實上就是三個步驟：
重現(Reproduce)，評估(Evaluate)，和調試(Debug)。這三個步驟已經讓我能夠快速識別Bug的來源並快速的除掉它。c以下是詳細的步驟：

 

重現(Reproduce)
重現一個 bug，除了驗證它確實存在，也是為了找到一個測試案例供解決時使用。能夠自信地測試您的解決方案對確保解掉這個bug 至關重要。(譯註:常常有程式員看到Bug描述，就想當然的認為如何如何，結果可與之相反，這樣的狀況屢見不鮮。重現是第一步，特別是理解Bug背後的意圖，就像是軟體開發中的需求之於設計一樣重要。)

 

評估(Evaluate)
面對Bug, 大多數開發人員會將時間花在這裡。坦率地說，這是錯誤的。評估應當用於找出一些顯而易見的問題 （錯誤字元、 錯誤的常量等），然後偵錯工具，這樣可以快速從代碼中隔離出來這個Bug。解bug需要更多地關注代碼。評估很重要，但不能靠它來解掉bug。

 

調試(Debug)
這是最重要的一步。一旦確定了Bug出現的位置，就要以逐步執行的方式跟蹤代碼並加以分析。Bug 往往更多地取決於程式的狀態，而不是它的位置。如果一個Bug發生是因為某個不應該為NULL的變數卻賦成了NULL，那麼這個Bug的根本原因可能在此位置之前了。(代碼死掉的位置並不一定是Bug存在的位置)。
代碼的運行狀態比代碼本身更重要。運用調試可以讓你真正瞭解程式的運行狀態。一行一行地逐步執行程式可以最終發現您的代碼在哪裡出錯了和什麼狀態導致了這個問題。只有瞭解了代碼為什麼出錯，而不是只瞭解代碼在什麼位置出錯，才能找出最佳的解決方案。

例如，剛剛提到的那個Bug可以有兩種方案：
  1. 添加判斷，以確認該變數不是NULL。
  2. 消除所有可能導致此變數為NULL值的情況。

 

第一種方法有時可能是正確的。但如果在設計時該變數無論在哪裡都不應為空白，那這樣做就有問題了。這樣做只會暫時掩飾掉它，而以後可能就要花更多的時間來解決變數為NULL的情況了。

如果先確定導致該變數為NULL的所有情況，對於先前的設計，消除掉這些異常的情況，這樣才算真正解掉了這個bug。解bug應當是修複代碼中的缺陷，而不只是隱藏起來。

 

(譯註：我比較推薦習慣用思維導圖的方式來思考，避免思維障礙，並具有普遍懷疑的精神。在軟體這個行當，主觀經驗是經常騙人的! (參考<<軟體開發之韻>> 2.3經驗式管理)

另一個有價值的參考:
 Avoid Side Effects

)