三問助你debug

譯者按: Debug也要三省吾身！

• 原文: Three Questions About Each Bug You Find

• 譯者: Fundebug

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原作者所有，翻譯僅用于學習。

你是否發現：有時候，當某個BUG被我們修復之后，卻又發現一個由該BUG引發的另一個BUG，或則由于修復算法的缺陷引入新的BUG？因此，每一次修復BUG，我都會問自己三個問題來確保我考慮周全。你也可以使用同樣的方法來提高代碼的質量。

這些精心設計的問題的核心思想是：每一個BUG都是某個隱藏的核心問題的表象。你需要解決這些表面癥狀，但如果只是治標，那么終究會在其它地方復發，沒有治本；你需要發現導致這個BUG的核心問題，并且糾正它。導致出現BUG的核心問題一般不會隨機而無法控制，只要你理解了它為什么會出現以及什么原因導致它出現。

在你對自己提出這三個問題之前，你需要克服自己的惰性，仔細地去分析產生BUG的原因。通過從出現BUG的代碼位置開始，一步一步問自己為什么會錯，往回倒著查看程序執行步驟，直到你找到出現這個BUG的模式。往往和同事一起Debug會有助于你證實你的假設。

程序異常是因為下標變量J越界了
為什么呢？
數組的長度為10，下標最大為9，但是下標J已經是10了
為什么呢？
J是整個數組的長度，但是可索引的下標為9。

在尋找BUG原因的過程中，同時檢查一下關鍵變量的值，看看能否解釋在此情況下，變量值為何如此。

為什么name是null？
為什么會打印出一條錯誤信息？

你需要知道程序到底發生了什么，也就是說要將這些信息度都記錄下來方便分析。

現在我們來看是看這三個問題。

1. 這個失誤在其它地方有犯過么？

看看代碼中其它地方有沒有使用過類似的編程方法，通過適當的發散思維也有助于尋找類似的BUG。

1. 其它地方有沒有使用數組的長度作為下標？
2. 所有的數組都是源自同一個原始數組嗎？
3. 如果數組長度為0，是否會出問題？

嘗試描述這段代碼應當遵循的邏輯，有BUG的代碼會違反該邏輯。

數組起點的初始值加上數組的長度并減去1就是最后一個數組元素的下標。如果數組的長度為0，則不滿足。

如果每次修改一個BUG的同時修復了幾個其它潛在BUG，將大大提高你的工作效率。嘗試將問題用更加抽象的角度去描述將有助于你理解整個程序，以防止引入新的BUG。

2. 在這個BUG后面是否可能隱藏著另一個BUG？

當你已經弄清楚如何修復這個BUG，可以預想BUG修復后的程序行為。BUG代碼行之后的語句也可能隱藏著BUG，只是程序以前因為BUG崩潰而沒有執行到這一步；或則由于修復可能返回其它值，而以前沒有考慮。可以試試向自己提如下問題：

接下來的語句可以成功執行嗎？

當你在查看程序的控制流的時候，你可以弄清楚有哪些代碼還沒有執行過。

我是否測試過這些屬性的組合

檢查各種屬性可能性的組合并不會花費太多工作精力，而且往往會發現很多情況開發者都沒有考慮到！

我可以測試出所有錯誤信息嗎？

要注意一個地方的改動可能導致其它地方出現BUG。在局部對一個變量的更改也許會違背之前的一些假設。

如果我只是將J減去1，如果數組的長度為0，那么下一行代碼會嘗試操作數組中位于-1位置的元素。

如果你已經對程序做了很多修改，每一次都要仔細考慮做法是否正確，甚至需要重新設計和實現這部分代碼。

3. 我應該如何做來避免類似的BUG？

你需要嘗試尋找方法從根源上解決問題。使用新的方法和工具往往可以直接消除該類型的所有BUG，而不是一個一個去發現和解決。

要找到BUG是什么時候引入的，是否可以在開發階段避免？

設計沒有問題；我在寫代碼的時候引入了BUG

仔細檢查BUG發生的原因，理清BUG發生的代碼邏輯，然后看看如何糾正。

定義新的不同的類型來區分數組的索引和長度可以在編譯時發現這個錯誤。(索引類型可以限定索引的最大長度)

每一個數組元素輸出的時候都輸出對應的下標的計算方法，這樣我就可以很快找到問題。

假設你對產生某一個BUG的理由是“變量太多，我只是忘記了”，那么你需要做的是如何改進來保證你不需要記住很多變量。

關于Fundebug

Fundebug專注于JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了7億+錯誤事件，得到了Google、360、金山軟件、百姓網等眾多知名用戶的認可。歡迎免費試用！

版權聲明

轉載時請注明作者Fundebug以及本文地址：
https://blog.fundebug.com/2017/08/23/three-questions-about-each-bug-you-find/