那些年bug總結出來的調試代碼技巧

尋找觸發條件，正所謂百分之百復現的bug都是好bug，百年不遇的bug都是上帝的恩賜。修改bug之前首先要找到bug，與測試、客戶溝通，現場試驗、還原資料庫，模擬運行環境等等動用一切力量，不惜一切代價找尋bug的觸發條件，找到bug觸發條件就說明修改bug已經成功一半了（PS：此處可能會有驚喜，沒準不是你寫的代碼有問題，是運行環境、硬體設備等問題）。

在調試前還需要先收集對調試有利的信息，比如log日誌等，這樣就比較容易快速定位到bug位置，可以起到事半功倍的效果。接下來就開始調試代碼，如果有log日誌就可以直接定位到錯誤的代碼行debug下，根據錯誤信息修改bug，如果沒有log日誌，那麼就準備持久戰吧。

首先可以利用二分查找法，這裡多適用於多表聯查sql語句中使用，當然代碼也可以，也就注掉一部分代碼或者幾個關聯表，慢慢找到有問題的代碼塊或資料庫表，找到出問題的癥結點。這個方法適用於不明確bug出現在哪裡，效率頗高。

接下來就是斷點調試了，debug的出現使程序員減少了很多負擔，尋找bug效率大幅度提升，debug可以使我們思路清晰，步步為營，如果代碼有問題，debug一定會捕捉到，正所謂不會debug的程序員不是好程序員。

當然還有種業務邏輯錯誤的，對於我們來說可以試試了解下業務邏輯，然後和代碼對比，看看哪裡不一樣，還有高手們是可以直接在業務邏輯中發現錯誤的。

還有一部分比如歷史遺留bug，我們是修改bug的，改的同時還要挖新的坑，補丁、版本都是上古時代的代碼，這種千瘡百孔的程序，我們在時間上允許的話可以重寫。重寫代碼同樣適用於邏輯不是很多、業務簡單的程序中，往往重寫比修改效果更好。

最後就是終極調試大法：小黃鴨調試法（又稱橡皮鴨調試法，黃鴨除蟲法，傳說中的大師都是隨身攜帶小黃鴨的，遇到bug就向小黃鴨解釋每一行代碼的用處，可能講到一半就靈光乍現，bug灰飛煙滅。通常就是你遇到bug解決不掉就向同事傾訴，剛說到一半突然就發現問題出現在哪裡了，回去修改bug留下一臉懵逼的同事在風中凌亂。但是在程序員中，同事是習慣了的，這就是小黃鴨的作用。

（圖片來自網路）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！