三問助你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。

其它地方有沒有使用陣列的長度作為下標？

所有的陣列都是源自同乙個原始陣列嗎？

如果陣列長度為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的理由是「變數太多，我只是忘記了」，那麼你需要做的是如何改進來保證你不需要記住很多變數。