用醫生的思考方式調試你的代碼

作者: Connor Mendenhall 來源: 碼農網發布時間: 2015-07-27 08:27 閱讀: 5674 次推薦: 5 原文鏈接 [收藏]

“現在的編程工作就像是對你需要解決處理的部分做科學研究。”
——Gerald Sussman

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

　　一點都不簡單。

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

　　當軟件系統中發生意外情況時，會造成很嚴重的后果。幸運的是，軟件開發人員可以借鑒另一門更古老的學科，來應對對于復雜系統的關注、維護和調試，這門學科就是——醫學。

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

列出所有觀察到的癥狀。
列出可能的病因。
按輕重緩急給這些病因排名。
按照優先順序進行測試，以排除病因。

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

　　白板是個好東西

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

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

　　斑馬和馬

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

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

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

　　重中之重，不能有害

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

　　準備圖表

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

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