三問助你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以及本文地址：
https://blog.fundebug.com/2017/08/23/three-questions-about-each-bug-you-find/