設(shè)計和維護好的軟件就像是一個抵制復(fù)雜度的永無止境的奮斗過程。任何足夠大小的應(yīng)用程序的代碼路徑和組件都能迅速成長成令人眼花繚亂的組合爆炸

一點都不簡單。

當部署類似于Heroku和AWS的平臺時，單服務(wù)器的Web應(yīng)用程序成為了分布式系統(tǒng)?，F(xiàn)代瀏覽器模糊了客戶端和服務(wù)器之間的界線。當簡單程序在 多個CPU內(nèi)核上運行時，它們就會成為復(fù)雜的協(xié)調(diào)問題。雖然像測試驅(qū)動開發(fā)等實踐和SOLID原則等指導(dǎo)，可以幫助我們模擬問題，簡化解決方案，但大多數(shù) 軟件應(yīng)用程序都是一些復(fù)雜的系統(tǒng)，每個組件也會以意想不到的方式進行交互和組合。

當軟件系統(tǒng)中發(fā)生意外情況時，會造成很嚴重的后果。幸運的是，軟件開發(fā)人員可以借鑒另一門更古老的學(xué)科，來應(yīng)對對于復(fù)雜系統(tǒng)的關(guān)注、維護和調(diào)試，這門學(xué)科就是：醫(yī)學(xué)。

[[136924]]

鑒別診斷是醫(yī)生用來匹配系列癥狀及其可能病因的系統(tǒng)化方法。一個好的鑒別診斷包括以下4個步驟：

1. 列出所有觀察到的癥狀。
2. 列出可能的病因。
3. 按輕重緩急給這些病因排名。
4. 按照優(yōu)先順序進行測試，以排除病因。

雖然上面這4個步驟是為醫(yī)生而整理的，但是我們同樣可以像一個醫(yī)生一樣思考，用一種強有力的方式來找到并消除軟件缺陷。將診斷過程分解為一個一個目 的單一的步驟，確保每個步驟都能得到應(yīng)有的重視。按照優(yōu)先順序是為了保證專注檢查的重點，并作出務(wù)實的干預(yù)措施。然后進行測試，排除假設(shè)，以確保調(diào)試的嚴 謹。

白板是個好東西

當錯誤發(fā)生時，我們大多會想也不想地立馬去調(diào)查最可能的原因。懂得向后跟蹤和少許背景知識，人性就會趨向于投機主義。但是好的診斷始于列出的癥狀， 而不是病因。寫下可以觀察出來的所有癥狀，無論是異常處理，還是錯誤代碼，哪怕只是異常的行為，都可以。可以使用文本編輯器或者白板，但是，你***能對診 斷過程中的每一個步驟做筆記，這很重要。從假設(shè)出發(fā)分開觀察，有助于確保你不會排除或忽視潛在原因。并且多數(shù)時候，列出更多的癥狀反而會縮小可能范圍，避 免你將時間浪費在測試不正確的假設(shè)上。

寫好了一系列癥狀，那么接下來就可以開始考慮原因了。

斑馬和馬

“當你聽到馬蹄聲的時候，找的應(yīng)該是馬，而不是斑馬。”

在應(yīng)用程序中出現(xiàn)代碼bug的可能性比在Web框架中出現(xiàn)bug的可能性要大，而在Web框架中發(fā)現(xiàn)bug又比在操作系統(tǒng)中發(fā)現(xiàn)bug更容易。當然 讓別人來審查代碼是個好主意，但事實是，大多數(shù)bug審查起來特別無聊。所以在開始考慮進階到更復(fù)雜的問題之前，先給出最簡單的解釋。

話又說回來，正如同一個癥狀卻又可能是完全不同的病因引發(fā)的，所以我們應(yīng)該將所有能想到的相關(guān)病因都寫下來。就像原先我們對癥狀直接描述為 “what”，后來用“how”區(qū)分開來，頭腦風暴解釋法的目的是用“how likely”來區(qū)分“how”。捕捉任何看似合理的要點，以便于節(jié)約分析。

重中之重，不能有害

鑒別診斷與其他的演繹方法不同，因為醫(yī)生必須不斷地評估風險，并權(quán)衡對病人生命的影響。當然如果我們的產(chǎn)品中存在著bug，雖然不會像醫(yī)生那樣負有 生命責任那般嚴重，但是停頓修復(fù)會產(chǎn)生既現(xiàn)實又痛苦的成本費用。就像威脅生命的疾病事件一樣需要立即進行干預(yù)，嚴重的bug可能需要粗暴的簡單修復(fù)，例如 回滾和重新啟動。將假設(shè)按優(yōu)先順序排列，然后再考慮權(quán)衡，并判斷決定是否啟動測試假設(shè)或立即進行干預(yù)。

準備圖表

正如患者會有醫(yī)院病歷和其他背景信息的圖表，你的軟件系統(tǒng)可能也需要具備圖表。從日志和錯誤報告系統(tǒng)收集信息，來說明你的分析。至于系統(tǒng)指標和跟蹤誤差，你不妨將它們當作是明智的預(yù)防性藥品。

如果你的病人尚未處于嚴重危險之中，那么可以先進行假設(shè)-演繹。從你定義的優(yōu)先級***的假設(shè)開始，一個一個地證明它們是錯誤的。雖然支持性證據(jù)有時 候或許能有助于你找到bug的所在，但是失敗的測試驅(qū)動了演繹過程。這乍一看上去似乎有悖直覺，但是測試-消除假設(shè)策略是追溯bug到它的起因的最快方 式。在許多情況下，一些簡單的測試就可以一次消除幾個假設(shè)。當然，也有時候，為了否決假設(shè)你就得執(zhí)行更多的測試。

實驗室工作

不同于醫(yī)療世界的令人難以接受，只要你愿意，你隨時都可以克隆軟件應(yīng)用程序，執(zhí)行可怕的人體實驗。如果你有足夠的信息來觸發(fā)你要診斷的bug，那么 可以將它復(fù)制到受控環(huán)境中，例如一個有著***數(shù)據(jù)庫備份的臨時服務(wù)器。當你消滅原因，收集到新的數(shù)據(jù)，并完善假設(shè)之后，你的bug的真正原因線索將變得更 加清晰。

清楚地思考復(fù)雜系統(tǒng)需要的關(guān)心和專注。采用結(jié)構(gòu)化的診斷過程來指導(dǎo)檢查可以節(jié)省時間和避免挫折感。最重要的是，它 很有用。下次你再陷入bug之中時，那么不妨試試拋開鍵盤，將步驟一步一步寫到白板上，像一個醫(yī)生診病一樣進行調(diào)試。

譯文鏈接：http://www.codeceo.com/article/debug-like-doctor.html
英文原文：Debug like a doctor
翻譯作者：碼農(nóng)網(wǎng) – 王國峰