譯者按: Debug也要三省吾身！
為了保證可讀性，本文采用意譯而非直譯。另外决记，本文版權(quán)歸原作者所有，翻譯僅用于學(xué)習(xí)。
你是否發(fā)現(xiàn)：有時候危纫，當(dāng)某個BUG被我們修復(fù)之后，卻又發(fā)現(xiàn)一個由該BUG引發(fā)的另一個BUG乌庶，或則由于修復(fù)算法的缺陷引入新的BUG种蝶？因此，每一次修復(fù)BUG瞒大，我都會問自己三個問題來確保我考慮周全螃征。你也可以使用同樣的方法來提高代碼的質(zhì)量。
這些精心設(shè)計的問題的核心思想是：每一個BUG都是某個隱藏的核心問題的表象透敌。你需要解決這些表面癥狀盯滚，但如果只是治標(biāo)，那么終究會在其它地方復(fù)發(fā)酗电，沒有治本魄藕；你需要發(fā)現(xiàn)導(dǎo)致這個BUG的核心問題，并且糾正它撵术。導(dǎo)致出現(xiàn)BUG的核心問題一般不會隨機(jī)而無法控制背率，只要你理解了它為什么會出現(xiàn)以及什么原因?qū)е滤霈F(xiàn)。
在你對自己提出這三個問題之前，你需要克服自己的惰性退渗，仔細(xì)地去分析產(chǎn)生BUG的原因移稳。通過從出現(xiàn)BUG的代碼位置開始，一步一步問自己為什么會錯会油，往回倒著查看程序執(zhí)行步驟个粱，直到你找到出現(xiàn)這個BUG的模式。往往和同事一起Debug會有助于你證實(shí)你的假設(shè)翻翩。
程序異常是因?yàn)橄聵?biāo)變量J越界了
為什么呢都许？
數(shù)組的長度為10，下標(biāo)最大為9嫂冻，但是下標(biāo)J已經(jīng)是10了
為什么呢胶征？
J是整個數(shù)組的長度，但是可索引的下標(biāo)為9桨仿。
在尋找BUG原因的過程中睛低，同時檢查一下關(guān)鍵變量的值，看看能否解釋在此情況下服傍，變量值為何如此钱雷。
為什么name是null？
為什么會打印出一條錯誤信息吹零？
你需要知道程序到底發(fā)生了什么罩抗，也就是說要將這些信息度都記錄下來方便分析。
現(xiàn)在我們來看是看這三個問題灿椅。
1. 這個失誤在其它地方有犯過么套蒂？
看看代碼中其它地方有沒有使用過類似的編程方法，通過適當(dāng)?shù)陌l(fā)散思維也有助于尋找類似的BUG茫蛹。
- 其它地方有沒有使用數(shù)組的長度作為下標(biāo)操刀？
- 所有的數(shù)組都是源自同一個原始數(shù)組嗎？
- 如果數(shù)組長度為0婴洼，是否會出問題骨坑？
嘗試描述這段代碼應(yīng)當(dāng)遵循的邏輯，有BUG的代碼會違反該邏輯窃蹋。
數(shù)組起點(diǎn)的初始值加上數(shù)組的長度并減去1就是最后一個數(shù)組元素的下標(biāo)卡啰。如果數(shù)組的長度為0，則不滿足警没。
如果每次修改一個BUG的同時修復(fù)了幾個其它潛在BUG匈辱，將大大提高你的工作效率。嘗試將問題用更加抽象的角度去描述將有助于你理解整個程序杀迹，以防止引入新的BUG亡脸。
2. 在這個BUG后面是否可能隱藏著另一個BUG？
當(dāng)你已經(jīng)弄清楚如何修復(fù)這個BUG，可以預(yù)想BUG修復(fù)后的程序行為浅碾。BUG代碼行之后的語句也可能隱藏著BUG大州，只是程序以前因?yàn)锽UG崩潰而沒有執(zhí)行到這一步；或則由于修復(fù)可能返回其它值垂谢，而以前沒有考慮厦画。可以試試向自己提如下問題：
接下來的語句可以成功執(zhí)行嗎滥朱？
當(dāng)你在查看程序的控制流的時候根暑，你可以弄清楚有哪些代碼還沒有執(zhí)行過。
我是否測試過這些屬性的組合
檢查各種屬性可能性的組合并不會花費(fèi)太多工作精力徙邻，而且往往會發(fā)現(xiàn)很多情況開發(fā)者都沒有考慮到排嫌！
我可以測試出所有錯誤信息嗎？
要注意一個地方的改動可能導(dǎo)致其它地方出現(xiàn)BUG缰犁。在局部對一個變量的更改也許會違背之前的一些假設(shè)淳地。
如果我只是將J減去1，如果數(shù)組的長度為0帅容，那么下一行代碼會嘗試操作數(shù)組中位于-1位置的元素颇象。
如果你已經(jīng)對程序做了很多修改，每一次都要仔細(xì)考慮做法是否正確丰嘉，甚至需要重新設(shè)計和實(shí)現(xiàn)這部分代碼夯到。
3. 我應(yīng)該如何做來避免類似的BUG嚷缭？
你需要嘗試尋找方法從根源上解決問題饮亏。使用新的方法和工具往往可以直接消除該類型的所有BUG，而不是一個一個去發(fā)現(xiàn)和解決阅爽。
要找到BUG是什么時候引入的路幸，是否可以在開發(fā)階段避免？
設(shè)計沒有問題付翁；我在寫代碼的時候引入了BUG
仔細(xì)檢查BUG發(fā)生的原因简肴，理清BUG發(fā)生的代碼邏輯，然后看看如何糾正百侧。
定義新的不同的類型來區(qū)分?jǐn)?shù)組的索引和長度可以在編譯時發(fā)現(xiàn)這個錯誤砰识。(索引類型可以限定索引的最大長度)
每一個數(shù)組元素輸出的時候都輸出對應(yīng)的下標(biāo)的計算方法，這樣我就可以很快找到問題佣渴。
假設(shè)你對產(chǎn)生某一個BUG的理由是“變量太多辫狼，我只是忘記了”，那么你需要做的是如何改進(jìn)來保證你不需要記住很多變量辛润。
關(guān)于Fundebug
Fundebug專注于JavaScript膨处、微信小程序、微信小游戲、支付寶小程序真椿、React Native鹃答、Node.js和Java實(shí)時BUG監(jiān)控。 自從2016年雙十一正式上線突硝，F(xiàn)undebug累計處理了7億+錯誤事件测摔，得到了Google、360解恰、金山軟件避咆、百姓網(wǎng)等眾多知名用戶的認(rèn)可。歡迎免費(fèi)試用修噪！
版權(quán)聲明:
轉(zhuǎn)載時請注明作者Fundebug以及本文地址：
https://blog.fundebug.com/2017/08/23/three-questions-about-each-bug-you-find/
