筆記|軟件調試的技巧

這篇文章是《調試九法：軟硬件錯誤的排查之道》的閱讀筆記。這本書的主旨，是介紹如何修復bug：找出bug發生的緣由、並給出修復方案。

調試bug的九個規則列舉以下，建議將這個清單打印出來，擺放在工做時候能看到的地方。

調試規則

接下來一次看下每一個規則的核心理念，從名字上來看，每一個規則看起來都比較明顯（PS：因爲翻譯的問題，有些詞可能沒那麼容易理解），可是理解這些規則和應用這些規則中間仍是差了不少距離的。

規則1：理解系統

你必須掌握系統的工做原理以及它是如何設計的，在某些狀況下還要知道爲何這樣設計。若是你沒有理解系統中的某個部分，那麼這一般是出問題的地方。（這不只僅是墨菲定律的問題，若是你不能理解你所設計的系統，你的工做可能會變得一團糟）。

如何理解系統呢？

• 閱讀手冊
• 逐字逐句閱讀手冊，仔細理解每一個細節
• 知道什麼是正常的，知道什麼是正常的能夠幫助你注意到什麼是不正常的
• 知道工做流程，要理解業務，要講系統的工做過程對應到具體要解決的現實問題
• 選擇合適的工具，選擇合適的輔助（監控、插樁）工具能夠幫你理解系統
• 查閱細節，經驗有時候會騙人，記憶有時候會出錯

規則2：製造失敗

這一點比較容易理解，就是問題復現，在平常工做中，你在排查一個問題的過程當中，最重要的一步就是復現問題——能復現的問題都能解決。

這裏有幾個要點須要注意：

• 引起失敗，而不要模擬失敗，不要嘗試用不一樣的方式去模擬問題，而要模擬和構建引起bug發生的條件
• debug的動做，不要影響錯誤的發生方式，能夠影響錯誤的發生頻率
• 從頭開始，須要有一個正常的狀態到不正常的狀態的過程，從開始正常的狀態開始觀察，直到問題發生；
• 終極方案，控制變量法，將可能引起錯誤的因素依次排除；排除全部可能的緣由後，剩下那個答案，不管多麼難以想象，都是事實。

規則3：不要想，而要看

親眼看到底層的失敗是很是重要的，若是你猜想失敗是如何發生的，那經常會修復一些根本不是bug的問題。

在軟件世界裏，觀察意味着設置斷點、添加調試語句、監視程序值以及檢查內存；在醫學領域，須要測試血樣和進行X光透視。

對細節的觀察應該到什麼程度合適呢？簡單的答案是：一直觀察，直到把問題的緣由鎖定在幾種可能以內。

在系統設計的時候，就要考慮到未來調試、排查問題的狀況，將日誌視爲系統設計的一部分—打印一些關鍵日誌，或者設計一些打開日誌的開關，以便在生產環境針對某個case進行調試。

平常生活中有不少插樁的case：

• 體溫計測量體溫
• 自行車輪胎漏氣時，都是將輪胎打滿氣，而後放在水裏檢查哪裏漏氣
• 自然氣中加入了臭雞蛋的氣味

規則4：分而治之

反覆將問題分紅好的一半和壞的一半，而後縮小搜索範圍，而後進一步研究有問題的那一半鏈路。

規則5：一次只改一個地方

初中就學過的控制變量法。
在修改bug時候，若是某個改動沒有修復bug，就應該當即把它改回來。

規則6： 保持審計跟蹤

記下你的每步操做、順序和結果；
魔鬼藏在細節中；
將一些事情關聯起來思考；
好記性不如爛筆頭；

規則7：檢查插頭

一些顯而易見的假設多是錯誤的；是否是運行了正確的代碼？是否是打了正確的包？插頭是否是掉了？從一些最基本的問題開始確認，不少時候問題就出在這裏。對本身使用的工具進行測試，由於工具也是一種軟件，難保不會出問題。

規則8：得到全新觀點

「要想從新理清一個案子的頭緒，最好的方法就是把它講給別人聽。」 ——福爾摩斯，《銀色馬》

向別人解釋問題的過程，會讓你對問題進行從新的梳理和理解，這時候可能發現以前沒有發現的問題。

bug發生了，以除掉bug爲自豪，而不是非得以本身除掉bug才自豪。

無論你是跟什麼人求助，或者須要別人什麼樣的幫助（徵求意見、獲取專業知識、聽取經驗），在向別人描述問題的時候，必定要記住一件事——報告症狀、而不是講你的理論；另外，有些症狀你可能不是十分肯定，也能夠描述出來。

規則9：若是你不修復bug，它將依然存在

「當危險已經離你很近時，拒絕認可它並非勇敢的表現，而是愚蠢。」 ——福爾摩斯，《最後一案》

若是你不修復bug，它不會自動消失。按照前面的規則解決問題後，要進行一次迴歸驗證，確保已經修復問題，而且沒有引入新的問題。

個人感想

這本書裏的不少案例都是是硬件相關的，對於軟件開發工程師來講不太熟悉，不過在閱讀的過程當中，建議能夠想一想本身在工做中排查問題的場景，是否是按照必定的章法去排查的？有沒有從最基本的假設開始確認？有沒有查閱文檔？有沒有關注本次變動的內容？有沒有按照二分法進行排除？

做爲軟件開發工程師，在實際工做中不多有機會從0開始構建一個系統，更常見的狀況是接手維護一個已經運行了幾年、經歷了幾代的系統。寫代碼只是工做中的一部分，還有不少其餘的事情須要作：修復bug、需求評審、系分評審、項目排期等等。

修復bug（解決問題）的能力，是軟件工程師的核心競爭力之一。在最開始的工做中，有時候會羨慕老司機的「直覺」——看到一個錯誤日誌，就大概知道是哪裏有問題，後來本身查問題查得多了以後，本身也get到了這種「直覺」，也理解了——這不是直覺，這是已經被實踐驗證過不少次的經驗，即便這樣，我也會告誡本身——不能徹底依賴這種經驗，經驗有助於縮小待驗證的範圍，仍是須要事實（重現問題）去證明前面的猜想。

---

本號專一於後端技術、JVM問題排查和優化、Java面試題、我的成長和自我管理等主題，爲讀者提供一線開發者的工做和成長經驗，期待你能在這裏有所收穫。