用醫生的思考方式調試你的代碼
設計和維護好的軟件就像是一個抵制復雜度的永無止境的奮斗過程。任何足夠大小的應用程序的代碼路徑和組件都能迅速成長成令人眼花繚亂的組合爆炸
一點都不簡單。
當部署類似于Heroku和AWS的平臺時，單服務器的Web應用程序成為了分布式系統。現代瀏覽器模糊了客戶端和服務器之間的界線。當簡單程序在 多個CPU內核上運行時，它們就會成為復雜的協調問題。雖然像測試驅動開發等實踐和SOLID原則等指導，可以幫助我們模擬問題，簡化解決方案，但大多數 軟件應用程序都是一些復雜的系統，每個組件也會以意想不到的方式進行交互和組合。
當軟件系統中發生意外情況時，會造成很嚴重的后果。幸運的是，軟件開發人員可以借鑒另一門更古老的學科，來應對對于復雜系統的關注、維護和調試，這門學科就是：醫學。
鑒別診斷是醫生用來匹配系列癥狀及其可能病因的系統化方法。一個好的鑒別診斷包括以下4個步驟：
- 列出所有觀察到的癥狀。
- 列出可能的病因。
- 按輕重緩急給這些病因排名。
- 按照優先順序進行測試，以排除病因。
雖然上面這4個步驟是為醫生而整理的，但是我們同樣可以像一個醫生一樣思考，用一種強有力的方式來找到并消除軟件缺陷。將診斷過程分解為一個一個目 的單一的步驟，確保每個步驟都能得到應有的重視。按照優先順序是為了保證專注檢查的重點，并作出務實的干預措施。然后進行測試，排除假設，以確保調試的嚴 謹。
白板是個好東西
當錯誤發生時，我們大多會想也不想地立馬去調查最可能的原因。懂得向后跟蹤和少許背景知識，人性就會趨向于投機主義。但是好的診斷始于列出的癥狀， 而不是病因。寫下可以觀察出來的所有癥狀，無論是異常處理，還是錯誤代碼，哪怕只是異常的行為，都可以。可以使用文本編輯器或者白板，但是，你***能對診 斷過程中的每一個步驟做筆記，這很重要。從假設出發分開觀察，有助于確保你不會排除或忽視潛在原因。并且多數時候，列出更多的癥狀反而會縮小可能范圍，避 免你將時間浪費在測試不正確的假設上。
寫好了一系列癥狀，那么接下來就可以開始考慮原因了。
斑馬和馬
“當你聽到馬蹄聲的時候，找的應該是馬，而不是斑馬。”
在應用程序中出現代碼bug的可能性比在Web框架中出現bug的可能性要大，而在Web框架中發現bug又比在操作系統中發現bug更容易。當然 讓別人來審查代碼是個好主意，但事實是，大多數bug審查起來特別無聊。所以在開始考慮進階到更復雜的問題之前，先給出最簡單的解釋。
話又說回來，正如同一個癥狀卻又可能是完全不同的病因引發的，所以我們應該將所有能想到的相關病因都寫下來。就像原先我們對癥狀直接描述為 “what”，后來用“how”區分開來，頭腦風暴解釋法的目的是用“how likely”來區分“how”。捕捉任何看似合理的要點，以便于節約分析。
重中之重，不能有害
鑒別診斷與其他的演繹方法不同，因為醫生必須不斷地評估風險，并權衡對病人生命的影響。當然如果我們的產品中存在著bug，雖然不會像醫生那樣負有 生命責任那般嚴重，但是停頓修復會產生既現實又痛苦的成本費用。就像威脅生命的疾病事件一樣需要立即進行干預，嚴重的bug可能需要粗暴的簡單修復，例如 回滾和重新啟動。將假設按優先順序排列，然后再考慮權衡，并判斷決定是否啟動測試假設或立即進行干預。
準備圖表
正如患者會有醫院病歷和其他背景信息的圖表，你的軟件系統可能也需要具備圖表。從日志和錯誤報告系統收集信息，來說明你的分析。至于系統指標和跟蹤誤差，你不妨將它們當作是明智的預防性藥品。
如果你的病人尚未處于嚴重危險之中，那么可以先進行假設-演繹。從你定義的優先級***的假設開始，一個一個地證明它們是錯誤的。雖然支持性證據有時 候或許能有助于你找到bug的所在，但是失敗的測試驅動了演繹過程。這乍一看上去似乎有悖直覺，但是測試-消除假設策略是追溯bug到它的起因的最快方 式。在許多情況下，一些簡單的測試就可以一次消除幾個假設。當然，也有時候，為了否決假設你就得執行更多的測試。
實驗室工作
不同于醫療世界的令人難以接受，只要你愿意，你隨時都可以克隆軟件應用程序，執行可怕的人體實驗。如果你有足夠的信息來觸發你要診斷的bug，那么 可以將它復制到受控環境中，例如一個有著***數據庫備份的臨時服務器。當你消滅原因，收集到新的數據，并完善假設之后，你的bug的真正原因線索將變得更 加清晰。
清楚地思考復雜系統需要的關心和專注。采用結構化的診斷過程來指導檢查可以節省時間和避免挫折感。最重要的是，它 很有用。下次你再陷入bug之中時，那么不妨試試拋開鍵盤，將步驟一步一步寫到白板上，像一個醫生診病一樣進行調試。
譯文鏈接：http://www.codeceo.com/article/debug-like-doctor.html
英文原文：Debug like a doctor
翻譯作者：碼農網 – 王國峰
