（譯註 ：解bug時常發生分析時總感覺快找到答案了，而後面卻一再陷入僵局。比如，將執行緒同步問題引起的一些時而有，時而沒有的問題。分析時可能會認為這是個典型的執行緒同步問題，a執行緒沒有按照預期的方式改變某個變數，導致了b執行緒處理出錯。這樣的分析結果如果沒有除錯（debug）的支援，就有可能將開發者帶入死胡同，找出一大堆的解決方案可能都無法完整地解掉bug。一定要在每次陷入困境的時候，回頭想一想，還有沒有什麼被忽略了。在一開始就對問題進行充分的了解是十分必要的。下文中作者提供了乙個簡單的流程可供參考。）
過去兩年工作中，我竟然成了乙個擅長解bug的傢伙。真不知道為什麼偏偏是解bug成了自然而然的事。在這段時間裡我總結出了一套解bug的流程，簡稱為red方法吧（譯註：感 覺可以像是紅色警戒！）。不過，這也不是什麼新的方**了。事實上，它成為標準的軟體開發實踐已經有些年頭了。但是我依然見到許多開發者無法系統運用這個方法，總是被解bug弄得頭大。這就是寫這篇文章的原因。
red方法是什麼？它其實上就是三個步驟： 重現（reproduce），評估（evaluate），和除錯（debug）。這三個步驟已經讓我能夠快速識別bug的**並快速的除掉它。c以下是詳細的步驟：
重現（reproduce）
重現乙個 bug，除了驗證它確實存在，也是為了找到乙個
測試用例
供解決時使用。能夠自信地測試您的解決方案對確保解掉這個bug 至關重要。（譯註：常常有程式設計師看到bug描述，就想當然的認為如何如何，結果可與之相反，這樣的狀況屢見不鮮。重現是第一步，特別是理解bug背後的意圖，就像是軟體開發中的需求之於設計一樣重要。）
評估（evaluate）
除錯（debug）
這是最重要的一步。一旦確定了bug出現的位置，就要以單步執行的方式跟蹤**並加以分析。bug 往往更多地取決於程式的狀態，而不是它的位置。如果乙個bug發生是因為某個不應該為null的變數卻賦成了null，那麼這個bug的根本原因可能在此位置之前了。（**死掉的位置並不一定是bug存在的位置）。
**的執行狀態比**本身更重要。運用除錯可以讓你真正了解程式的執行狀態。一行一行地逐步執行程式可以最終發現您的**在**出錯了和什麼狀態導致了這個問題。只有了解了**為什麼出錯，而不是只了解**在什麼位置出錯，才能找出最佳的解決方案。
例如，剛剛提到的那個bug可以有兩種方案：
1、新增判斷，以確認該變數不是null。
2、消除所有可能導致此變數為null值的情況。
第一種方法有時可能是正確的。但如果在設計時該變數無論在**都不應為空，那這樣做就有問題了。這樣做只會暫時掩飾掉它，而以後可能就要花更多的時間來解決變數為null的情況了。
如果先確定導致該變數為null的所有情況，對於先前的設計，消除掉這些異常的情況，這樣才算真正解掉了這個bug。解bug應當是修復**中的缺陷，而不只是隱藏起來。
***********************************=分割線******************************==
如何有效地解Bug RED方法
解bug應當是修復 中的缺陷，而不只是隱藏起來 譯註 解bug時常發生分析時總感覺快找到答案了，而後面卻一再陷入僵局。比如，將執行緒同步問題引起的一些時而有，時而沒有的問題。分析時可能會認為這是個典型的執行緒同步問題，a執行緒沒有按照預期的方式改變某個變數，導致了b執行緒處理出錯。這樣的分析結果如果...
如何有效地報告Bug？
simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話，您可以省去推測，但是千萬別省略事實。然後，simon針對bug報告的不同問題分別提出了自己...
如何有效地報告Bug？
作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 ...