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

2021-09-30 21:39:49 字數 1648 閱讀 6046

(譯註 :解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報告裡,要設法搞清什麼是事實 ...