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