程序員是如何debug的呢？其實一個概念八個字就講完了：單一變量，對照實驗（controlled trial）。
「對照試驗」是最最基礎的科學實驗方法之一，在初中生物課本里就已經被掰開揉碎詳細教完了。按理說，任何一個讀完高中的人都沒理由不把這個科學思考方法吃到肚子里、融到血液中。可是環顧四周，卻處處可見不知「對照試驗」、「雙盲測試」（多加了條件的隨機對照試驗）精神為何物的成年人：只消看看你周圍還有多少中醫粉就知道了……
不過請放心，暫時做不到邏輯思考也不是世界末日，還可以通過學習編程來拯救自己的腦回溝！
對于程序員來說，不管是多隱藏的bug，都可以順著「對照試驗」的思路來debug。
實際上有一種寫程序的風格/方法就把「對照試驗」的精神發揮到了極致，它被稱為 Incremental Development（增量式開發）：
Incremental development:a program development plan intended to avoid debugging by adding and testing only a small amount of code at a time.
——Allen Downey (2015)
這種開發的思路就是每次只寫一點點代碼（即只增加一個確定的變量），測試沒問題了，再進行下一步。
不太了解軟件開發的讀者可能會想問：除了每次往下寫一點點，難道還有別的編程思路嗎？
有！
比如，你可以把每個重要部分的基本思路框架都寫個開頭結尾，再分別往里填充具體細節；你還可以龍卷風般地先把能寫的代碼都寫到底，最后再整體進行測試排除bug。
以上三種思路都是在開發單次版本的項目時的常見方法。如果把目光拉遠，著眼于整個項目交付的流程安排，那「快速迭代」是公認的最有效率的開發模式——即，先快速完成一個可用版本，之后發現有問題或出現新需求再不斷迭代推出新版本。
前者是個微觀角度，后者則是宏觀視角。
編程并不是什么特立獨行的事，你肯定也能在解決其他具體任務過程中找到以上三種編程風格的影子——
比如，在看書這件事上就能很輕易地發現對應以上三種風格的讀者：
小A們習慣從第一頁讀起，一個字一個字、一段一段、一頁一頁地，不搞懂前一句話什么意思，就絕不進行到下一句——你是「增量式閱讀」的信徒！
小B們則偏好先讀讀目錄，搞懂全書結構，每一章都挑開頭結尾段瀏覽瀏覽，再開始細讀具體內容——你是「框架式閱讀」的實踐者！
還有小C們，喜歡不管三七二十一，先龍卷風般把全書都粗讀一遍，最后有疑問或有意猶未盡的地方再跳回去重新細讀——你是「龍卷風式閱讀」的追隨者！
回到這篇短文的debug主題。不管你是哪種風格的程序員，最終排除所有干擾變量、捉住蟲（bug）的結局一定是——
「排除一切不可能的，剩下的即使再不可能，也是真相。」
「Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.」
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ——福爾摩斯
∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷
以上這篇短文原型基于我之前寫的一篇「觀察日記」主題短文。然而上周讀了安姐在她公眾號「嘀嗒嘀嗒」上發表的《面對 bug 的正確姿勢》（感興趣戳文末“參考鏈接”）后，深感“姜必須是老的辣”！我看同一件事的角度遠不如安姐成熟老練，當然身為高級工程師的安姐本來也是在實戰上輕松碾壓大部分菜鳥。受她文章的一點啟發，我于是把自己原來的文章敲打修補了一遍，新版本就暫且是這樣的了。
How to debug 肯定是個值得時新的話題，請容忍我目前淺顯的思考水平，期待自己以后積累更多實戰經驗與反思。
在你面對代碼里、生活中的 bug 時，有什么好的處理思路呢？歡迎在評論區分享給大家 :D
參考鏈接：https://mp.weixin.qq.com/s/yz4szTcJKiTbDQEsAnOFbA?
