摘要：在軟件世界里，觀察意味著設置斷點添加調試語句監視程序值以及檢查內存在醫學領域，需要測試血樣和進行光透視。福爾摩斯，最后一案如果你不修復，它不會自動消失。修復解決問題的能力，是軟件工程師的核心競爭力之一。

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

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

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

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

如何理解系統呢？

閱讀手冊

逐字逐句閱讀手冊，仔細理解每個細節

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

知道工作流程，要理解業務，要講系統的工作過程對應到具體要解決的現實問題

選擇合適的工具，選擇合適的輔助（監控、插樁）工具可以幫你理解系統

查閱細節，經驗有時候會騙人，記憶有時候會出錯

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

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

引發失敗，而不要模擬失敗，不要嘗試用不同的方式去模擬問題，而要模擬和構建引發bug發生的條件

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

從頭開始，需要有一個正常的狀態到不正常的狀態的過程，從開始正常的狀態開始觀察，直到問題發生；

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

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

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

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

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

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

體溫計測量體溫

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

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

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

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

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

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

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

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

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

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

“當危險已經離你很近時，拒絕承認它并不是勇敢的表現，而是愚蠢。” ——福爾摩斯，《最后一案》

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

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

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

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

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