每個大程式裡都有一個不安分的小程式——我們稱之為BUG
總結我的程式設計生涯，可以得出如下兩個硬道理：
（1）任何程式碼都可能出錯，而且肯定會出錯。
（2）程式碼有味道。
而中和這些苦澀現實的唯一方法就是除錯（Debug）。
沒錯，就是除錯。在剛開始接觸程式設計的時候，沒人會喜歡除錯。相反，除錯往往是沮喪和恐懼的根源。很多人心裡說：“我要浪費多少時間才能改好這個bug？”我們更加願意去構建很酷的東西。（試問誰不喜歡構建很酷的東西！？）
然而，所有我們欽佩的開發人員都認為除錯很重要。那是因為他們知道除錯對他們來說是提高自身實力的寶貴資源。在有些情況下，除錯能夠反映出開發人員的能力。
除錯的真正問題在於無法規劃所需的時間。所有程式設計活動——從設計到開發都可以有時間規劃。但除錯卻完全不同，除錯可能會花費一個小時、一天、甚至不知不覺一週就過去了，卻還是未能發現問題的根源並修復問題。
這就是你應該把除錯作為學習良機的原因。當然除錯很痛苦，但是通過正確的方法你也可以控制除錯。
以下是一些可以更好地進行除錯的方法。
首先了解系統
我們經常會犯一個錯誤：“先理解出現的問題”然後再“理解系統”，實際的順序應該反過來。
曾經有一段時間，我除錯過一個 SAP 智慧表單的問題。表單上的有些值顯示不正確，我花了兩天的時間除錯整個表單，仍然茫無頭緒。不用說，我的心情很沮喪。這個表單看起來似乎根本沒問題，後來我突然來靈感了——
我注意到主程式碼中有兩處同時呼叫了該表單。通過進一步分析，我發現問題出在呼叫該表單的程式碼中。我迅速解決了這個問題。我之前兩天的努力全白費了，事實上只需要在別的地方做一處小小的改動就可以解決問題。
那麼，我哪裡做錯了？
如果不理解這個系統的工作原理，那麼我就無法除錯這個問題。一旦明白了系統以後，問題就很明顯了。
請時刻牢記，你需要了解系統的應有行為、系統的設計，以及在某些情況下系統如此設計的原因 。如果你不理解系統的某些部分，那麼問題往往就會出現在你不瞭解的這些部分上。
分而治之
我付出了很大代價才明白了這個道理。
有一段時間，我參與了一個大型的 SAP 資料遷移專案。當時的時間非常緊迫，而且有很多程式碼塊同時開發。在這個節骨眼上，我遇到了資料損壞的問題。
一些遷移的客戶資料遭到了破壞，從幾百萬條記錄中找出哪些出了問題是一項無比艱鉅的任務。雖然我知道問題是什麼，但是問題出在什麼地方才是關鍵所在。
最後，我通過原型製作解決了這個問題。我建立了一個很小的原型，通過一套子資料集重現了類似的症狀。我通過這個原型找到了根本原因，並最終解決了問題。
解決問題的關鍵在於縮小搜尋範圍。
大型系統都很複雜，系統的執行涉及許多因素。從整體上來看系統，你很難區分出影響特定問題的細節。
解決方法是分而治之。不要著急著眼於整個系統，將有問題的元件或模組從程式碼中分離出來，才能進行嚴謹的除錯。
分離問題有許多優點。你可以只關注與問題相關的部分，由於程式碼量很少，所以你可以快速解決問題。
請時刻牢記，通過剝絲抽繭，逐步縮小範圍，最終 bug 將無藏身之處。
一次只做一個改動
就好比使用步槍，一槍一個眼；而不是霰彈槍，一槍炸一片。
想象一下，你去牙醫那裡拔牙。你的牙醫為了“設法”找到問題，開始對著你滿嘴的牙下手。他手中的錘子每敲一下，你就痛苦地呻吟一聲。
這時，你有何感受？你心裡肯定在犯嘀咕：“什麼情況啊？這個混蛋會不會給人看病啊？”
錯誤的除錯方式亦是如此。
一次只改動一個地方。如果你手中拿的是一把好步槍，那麼你可以更好地修復 bug。我見過有些開發人員試圖通過交換或修改其他元件來修復錯誤的程式碼。可能在他們改動了三四處程式碼後，發現可以正常工作了。這看似很酷，但是他們完全不知道哪個部分有問題。更糟糕的是，他們所做的這些改動很有可能破壞本來執行得好好的程式碼。
在很多情況下，你需要改動系統的不同部分，來看看是否對這個問題有影響。一般來說，這是一個警告，你並沒有充分地瞭解程式碼，而是在猜測。你只是在改變問題發生的條件，而不是尋找問題自然發生的原因。
這種做法會隱藏第一個問題的原因，還會導致更多問題的發生。這是開發人員都需要避免的錯覺陷阱。
請時刻牢記，如果一次只做一個改動，那麼你可以確切地知道哪個引數有效。如果改動看似沒有效果，那麼請立即恢復原樣！
檢查是否真的是由於你的改動才修復了 Bug
除錯的一個黃金法則是：如果不是你的改動修復了 bug，那麼這個 bug 就沒有得到修復 。
每個人都願意相信 bug 不藥而癒了——“似乎我們無法再重現這個 bug”——“這個 bug 出現了幾次，但後來不知道發生了什麼，不再重現了。”當然，合乎邏輯的結論是，“也許這個 bug 不會再發生。”但是，你猜怎麼著？它還會發生。
很抱歉讓你們失望，但現實世界中沒有神仙。
如果你覺得你已經修復了某個 bug，那麼你需要確保去掉你的改動後，這個 bug 會再次重現；還要確保加上改動後，bug 就會被修復。你需要重複從改好到重現再到改好的過程，只改動與修復 bug 有關的程式碼，否則就不能證明你修復了這個 bug。
修復 bug 往往很有意思。有時 bug 只是“隱藏了起來”而不是真正被解決了。有時候，當我們意識到我們的改動與要修復的 bug 無關時，產品早已發給了客戶，顯然他們不會滿意這種產品。所以，千萬不要掉入這樣的陷阱中。
請時刻牢記，如果去掉你改動的程式碼，那麼系統就會重現之前的 bug，只有這樣才能確保你的修改確實有效 。
最後，記錄你的解決方案
這項工作看似無關緊要，但其實是一個常常被忽略的非常重要的問題解決工具。問題在生活、工作甚至是長期的人際關係中反覆重演，我們沒必要一次又一次地重複造輪子。
關於解決方案日誌中實際記錄的資訊型別而言，考慮到業務之間的需求不同，所以很難下結論。但是，通常可以考慮如下幾項：
問題編號
彙報人（記錄通話的人）
彙報人的分機號碼或電話號碼
建立日期/時間
概要描述
影響/重要性
故障型別
系統的所有者
當前狀態（開放，正在處理，已關閉）
下一步
下一步的日期
完成日期
解決方案，開發請求編號或供應商支援請求的連結
不要在同一個地方跌倒兩次。為了提高工作效率，請記錄所遇到的問題以及最終的解決方案。遇到問題時，我們不必再說：“我以前見過這個問題，但我不知道怎麼解決。”你可以快速查詢過去使用過的解決方案。不用說，這種做法不僅可以節省你的時間，還可以大大地提高你的自尊和自信。
請記住，除錯是一個學習的良機。當然，有時你會意識到你犯了一個本不應該犯的愚蠢錯誤。但這也是成長為一名更好的開發者的必經之路，因為你可以藉機學習新知識。
Richard Pattis 有一句話說得很好：新手除錯時會新增矯正程式碼；而專家除錯時會刪除有缺陷的程式碼。
喜歡筆者文章並且想學習c/c++程式設計的小夥伴可以加Q群，648778840一起來交流哦，群內有很多學習資料可免費領取的！對於程式設計的初學者來說會特別有用的！另外筆者也會在Q群裡面進行視訊教學，大家有興趣的可以來哦！