摘要：在軟件世界里，觀察意味著設(shè)置斷點添加調(diào)試語句監(jiān)視程序值以及檢查內(nèi)存在醫(yī)學(xué)領(lǐng)域，需要測試血樣和進(jìn)行光透視。福爾摩斯，最后一案如果你不修復(fù)，它不會自動消失。修復(fù)解決問題的能力，是軟件工程師的核心競爭力之一。

這篇文章是《調(diào)試九法：軟硬件錯誤的排查之道》的閱讀筆記。這本書的主旨，是介紹如何修復(fù)bug：找出bug發(fā)生的原因、并給出修復(fù)方案。

調(diào)試bug的九個規(guī)則列舉如下，建議將這個清單打印出來，擺放在工作時候能看到的地方。

接下來一次看下每個規(guī)則的核心理念，從名字上來看，每個規(guī)則看起來都比較明顯（PS：由于翻譯的問題，有些詞可能沒那么容易理解），但是理解這些規(guī)則和應(yīng)用這些規(guī)則中間還是差了很多距離的。

你必須掌握系統(tǒng)的工作原理以及它是如何設(shè)計的，在某些情況下還要知道為什么這樣設(shè)計。如果你沒有理解系統(tǒng)中的某個部分，那么這通常是出問題的地方。（這不僅僅是墨菲定律的問題，如果你不能理解你所設(shè)計的系統(tǒng)，你的工作可能會變得一團(tuán)糟）。

如何理解系統(tǒng)呢？

閱讀手冊

逐字逐句閱讀手冊，仔細(xì)理解每個細(xì)節(jié)

知道什么是正常的，知道什么是正常的可以幫助你注意到什么是不正常的

知道工作流程，要理解業(yè)務(wù)，要講系統(tǒng)的工作過程對應(yīng)到具體要解決的現(xiàn)實問題

選擇合適的工具，選擇合適的輔助（監(jiān)控、插樁）工具可以幫你理解系統(tǒng)

查閱細(xì)節(jié)，經(jīng)驗有時候會騙人，記憶有時候會出錯

這一點比較容易理解，就是問題復(fù)現(xiàn)，在日常工作中，你在排查一個問題的過程中，最重要的一步就是復(fù)現(xiàn)問題——能復(fù)現(xiàn)的問題都能解決。

這里有幾個要點需要注意：

引發(fā)失敗，而不要模擬失敗，不要嘗試用不同的方式去模擬問題，而要模擬和構(gòu)建引發(fā)bug發(fā)生的條件

debug的動作，不要影響錯誤的發(fā)生方式，可以影響錯誤的發(fā)生頻率

從頭開始，需要有一個正常的狀態(tài)到不正常的狀態(tài)的過程，從開始正常的狀態(tài)開始觀察，直到問題發(fā)生；

終極方案，控制變量法，將可能引發(fā)錯誤的因素依次排除；排除所有可能的原因后，剩下那個答案，無論多么不可思議，都是事實。

親眼看到底層的失敗是非常重要的，如果你猜測失敗是如何發(fā)生的，那常常會修復(fù)一些根本不是bug的問題。

在軟件世界里，觀察意味著設(shè)置斷點、添加調(diào)試語句、監(jiān)視程序值以及檢查內(nèi)存；在醫(yī)學(xué)領(lǐng)域，需要測試血樣和進(jìn)行X光透視。

對細(xì)節(jié)的觀察應(yīng)該到什么程度合適呢？簡單的答案是：一直觀察，直到把問題的原因鎖定在幾種可能之內(nèi)。

在系統(tǒng)設(shè)計的時候，就要考慮到將來調(diào)試、排查問題的情況，將日志視為系統(tǒng)設(shè)計的一部分—打印一些關(guān)鍵日志，或者設(shè)計一些打開日志的開關(guān)，以便在生產(chǎn)環(huán)境針對某個case進(jìn)行調(diào)試。

日常生活中有很多插樁的case：

體溫計測量體溫

自行車輪胎漏氣時，都是將輪胎打滿氣，然后放在水里檢查哪里漏氣

天然氣中加入了臭雞蛋的氣味

反復(fù)將問題分成好的一半和壞的一半，然后縮小搜索范圍，然后進(jìn)一步研究有問題的那一半鏈路。

初中就學(xué)過的控制變量法。
在修改bug時候，如果某個改動沒有修復(fù)bug，就應(yīng)該立即把它改回來。

記下你的每步操作、順序和結(jié)果；
魔鬼藏在細(xì)節(jié)中；
將一些事情關(guān)聯(lián)起來思考；
好記性不如爛筆頭；

一些顯而易見的假設(shè)可能是錯誤的；是不是運行了正確的代碼？是不是打了正確的包？插頭是不是掉了？從一些最基本的問題開始確認(rèn)，很多時候問題就出在這里。對自己使用的工具進(jìn)行測試，因為工具也是一種軟件，難保不會出問題。

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

向別人解釋問題的過程，會讓你對問題進(jìn)行重新的梳理和理解，這時候可能發(fā)現(xiàn)之前沒有發(fā)現(xiàn)的問題。

bug發(fā)生了，以除掉bug為自豪，而不是非得以自己除掉bug才自豪。

不管你是跟什么人求助，或者需要別人什么樣的幫助（征求意見、獲取專業(yè)知識、聽取經(jīng)驗），在向別人描述問題的時候，一定要記住一件事——報告癥狀、而不是講你的理論；另外，有些癥狀你可能不是十分確定，也可以描述出來。

“當(dāng)危險已經(jīng)離你很近時，拒絕承認(rèn)它并不是勇敢的表現(xiàn)，而是愚蠢。” ——福爾摩斯，《最后一案》

如果你不修復(fù)bug，它不會自動消失。按照前面的規(guī)則解決問題后，要進(jìn)行一次回歸驗證，確保已經(jīng)修復(fù)問題，并且沒有引入新的問題。

這本書里的很多案例都是是硬件相關(guān)的，對于軟件開發(fā)工程師來說不太熟悉，不過在閱讀的過程中，建議可以想想自己在工作中排查問題的場景，是不是按照一定的章法去排查的？有沒有從最基本的假設(shè)開始確認(rèn)？有沒有查閱文檔？有沒有關(guān)注本次變更的內(nèi)容？有沒有按照二分法進(jìn)行排除？

作為軟件開發(fā)工程師，在實際工作中很少有機(jī)會從0開始構(gòu)建一個系統(tǒng)，更常見的情況是接手維護(hù)一個已經(jīng)運行了幾年、經(jīng)歷了幾代的系統(tǒng)。寫代碼只是工作中的一部分，還有很多其他的事情需要做：修復(fù)bug、需求評審、系分評審、項目排期等等。

修復(fù)bug（解決問題）的能力，是軟件工程師的核心競爭力之一。在最開始的工作中，有時候會羨慕老司機(jī)的“直覺”——看到一個錯誤日志，就大概知道是哪里有問題，后來自己查問題查得多了之后，自己也get到了這種“直覺”，也理解了——這不是直覺，這是已經(jīng)被實踐驗證過很多次的經(jīng)驗，即使這樣，我也會告誡自己——不能完全依賴這種經(jīng)驗，經(jīng)驗有助于縮小待驗證的范圍，還是需要事實（重現(xiàn)問題）去證實前面的猜測。

本號專注于后端技術(shù)、JVM問題排查和優(yōu)化、Java面試題、個人成長和自我管理等主題，為讀者提供一線開發(fā)者的工作和成長經(jīng)驗，期待你能在這里有所收獲。