作為 C++ 程序員，你對調(diào)試代碼是一種什么態(tài)度？英文原文：Debug like a doctor

“現(xiàn)在的編程工作就像是對你需要解決處理的部分做科學(xué)研究。”

——Gerald Sussman

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

　　一點都不簡單。

　　當部署類似于 Heroku 和 AWS 的平臺時，單服務(wù)器的 Web 應(yīng)用程序成為了分布式系統(tǒng)。現(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é)。

　　鑒別診斷是醫(yī)生用來匹配系列癥狀及其可能病因的系統(tǒng)化方法。一個好的鑒別診斷包括以下 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)試。

來源：U8K8.com

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的C++ 程序员要像医生一样调试代码？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。