（譯注 ：解Bug時常發(fā)生分析時總感覺快找到答案了，而后面卻一再陷入僵局。比如，將線程同步問題引起的一些時而有，時而沒有的問題。分析時可能會認為這是個典型的線程同步問題，A線程沒有按照預期的方式改變某個變量，導致了B線程處理出錯。這樣的分析結果如果沒有調試（Debug）的支持，就有可能將開發(fā)者帶入死胡同，找出一大堆的解決方案可能都無法完整地解掉Bug。一定要在每次陷入困境的時候，回頭想一想，還有沒有什么被忽略了。在一開始就對問題進行充分的了解是十分必要的。下文中作者提供了一個簡單的流程可供參考。）
過去兩年工作中，我竟然成了一個擅長解Bug的家伙。真不知道為什么偏偏是解Bug成了自然而然的事。在這段時間里我總結出了一套解bug的流程，簡稱為RED方法吧（譯注：感 覺可以像是紅色警戒！）。不過，這也不是什么新的方法論了。事實上，它成為標準的軟件開發(fā)實踐已經(jīng)有些年頭了。但是我依然見到許多開發(fā)者無法系統(tǒng)運用這個方法，總是被解Bug弄得頭大。這就是寫這篇文章的原因。
RED方法是什么？它其實上就是三個步驟： 重現(xiàn)（Reproduce），評估（Evaluate），和調試（Debug）。這三個步驟已經(jīng)讓我能夠快速識別Bug的來源并快速的除掉它。c以下是詳細的步驟：
重現(xiàn)（Reproduce）
重現(xiàn)一個 bug，除了驗證它確實存在，也是為了找到一個測試用例供解決時使用。能夠自信地測試您的解決方案對確保解掉這個bug 至關重要。（譯注：常常有程序員看到Bug描述，就想當然的認為如何如何，結果可與之相反，這樣的狀況屢見不鮮。重現(xiàn)是第一步，特別是理解Bug背后的意圖，就像是軟件開發(fā)中的需求之于設計一樣重要。）
評估（Evaluate）
面對Bug， 大多數(shù)開發(fā)者會將時間花在這里。坦率地說，這是錯誤的。評估應當用于找出一些顯而易見的問題 （錯誤字符、 錯誤的常量等），然后調試程序，這樣可以快速從代碼中隔離出來這個Bug。解bug需要更多地關注代碼。評估很重要，但不能靠它來解掉bug。
調試（Debug）
這是最重要的一步。一旦確定了Bug出現(xiàn)的位置，就要以單步執(zhí)行的方式跟蹤代碼并加以分析。Bug 往往更多地取決于程序的狀態(tài)，而不是它的位置。如果一個Bug發(fā)生是因為某個不應該為NULL的變量卻賦成了NULL，那么這個Bug的根本原因可能在此位置之前了。（代碼死掉的位置并不一定是Bug存在的位置）。
代碼的運行狀態(tài)比代碼本身更重要。運用調試可以讓你真正了解程序的運行狀態(tài)。一行一行地逐步執(zhí)行程序可以最終發(fā)現(xiàn)您的代碼在哪里出錯了和什么狀態(tài)導致了這個問題。只有了解了代碼為什么出錯，而不是只了解代碼在什么位置出錯，才能找出最佳的解決方案。
例如，剛剛提到的那個Bug可以有兩種方案：
1、添加判斷，以確認該變量不是NULL。
2、消除所有可能導致此變量為NULL值的情況。
第一種方法有時可能是正確的。但如果在設計時該變量無論在哪里都不應為空，那這樣做就有問題了。這樣做只會暫時掩飾掉它，而以后可能就要花更多的時間來解決變量為NULL的情況了。
如果先確定導致該變量為NULL的所有情況，對于先前的設計，消除掉這些異常的情況，這樣才算真正解掉了這個bug。解bug應當是修復代碼中的缺陷，而不只是隱藏起來。
原文出自：http://blog.csdn.net/horkychen/article/details/7686204