前言
你有沒有曾經調式某段代碼時，總覺得世界上有鬼？
你有沒有曾經調式API時，總感覺是調用第三方的接口問題或者文檔說明不對？
你有沒有曾經調式一個bug 時，總感覺問題的來源是使用的方式不對？
你有沒有在安裝一個服務時，總感覺文檔或者環境不相符合？
相信過程和方法，切勿被結果誤導 ............
概述
調式代碼很多時候類似於查案一樣，只是結果的重要程度不同，警察查案為的是人民安穩，而我們調式則是為了系統的安穩。既然這樣我們就不要冤枉任何一段代碼和程序，以免他們受到不合理的懲罰。
以下的一些過程方法都來自於個人的總結，從個人角度說前人的一些方法都是經過長期的經驗積累，當然參考性理論性都比較強，而作為個人的方法，則可能更適合像我等 DS 。
測試方法
代碼過程式調式方法
代碼調式首先要注意的是過程，你必須要理清楚導致最終結果的思路，也就是作案的過程，從作案過程中的一步步跟進得到作案結果。在作案過程分析中對於每一個疑點都必須打上標記（也就是代碼中所提到的 log 信息）。經過這樣的分析過程後，再進行黑盒測試，添加輸入，驗證結果。最終根據每一步的標記來驗證你的判斷，從而找到原因。
以上的方案是一種過程式的調式方式。這種方式的優點不言而喻，直接可以通過一個測試就可以分析清楚整個過程，但是這種方式很耗時間，理清楚自己的代碼邏輯尚可，而想要理清楚他人邏輯代碼則可要難於上青天。
單元測試調式方法
單元測試的基本目的是保證某個函數、類或者某個功能模塊的正常運作，包括其異常情況的測試驗證。而作為程序員最喜歡的驗證方式莫過於“打樁”（打樁的含義就是提供假默認數據），這種方式調式起來非常方便，但是有一個不利的地方就是無法再次利用，因為在我們驗證正常以後，很多開發人員都會將其注釋或者刪除，因此如果我們在開發環境開發完成，但我們希望在測試環境驗證時，則必須又要重新寫一篇打樁邏輯，那麼這樣看，到現網時，則會更加的麻煩。既然這麼多不便，你可以嘗試下面的做法。
添加一個單元測試類，這個類需要控制其權限，只有通過後台登錄或者是命令行才可以執行，該類承載的作用就是對系統的關鍵邏輯進行檢測，並且做出相應的測試輸出結果。要相信所有的接口類都是可以通過單元測試類去完成測試的。很多時候程序員在質疑，這件事情是不是應該我們做？其實還真是需要我們去做，畢竟很多測試現在做的都是黑盒測試。
這種調式方法適合在開發過程中，並且可以保證我們現網的代碼發布後運行正常。希望大家在計劃開發時間時也將該過程並於開發階段。
快速定位法
前面兩個那麼復雜的過程太理想化了？我的代碼就只有 100 行，並且系統也不復雜。如果是這樣的話，那麼就快速的進行定位分析。很多時候會遇到
1、輸入正常，輸出異常；
2、輸入正常，邏輯異常，輸出異常；
3、輸入異常，邏輯正常，輸出正常；
4、輸入異常，邏輯異常，輸出無。
在個人的開發過程中，我經常會遇到上面的某種類型的問題，比如在 Node.js 開發過程中，遇到 string.length 提示 string 沒有 length 方法。當時就昏頭的在問自己，為什麼其他 string 都有 length 方法，為什麼這個就沒有呢？應該很多同學都知道問題就在於這個 string 根本就不是 string ，只是說你自己把它理想化為 string 了，也就是你輸入的本來就有問題。那麼定位這個問題的最好辦法就是打印輸入，打印輸出即可。
可能其他的程序沒有這麼簡單，但是最基本的就是在主函數中的會遇到異常的函數都進行輸入輸出判斷，那樣就可以快速的定位。
切記：不要斷章取義，自以為是。
上面的方法以及過程都只是基於 PHP 或者 Node.js 總結出來的，對於 C & C++ 可能存在相似或者相異處。不喜勿噴，且看且珍惜吧。