在開發中，說下你奇葩的排錯思路，解決問題的巧妙方法？

01-08

從原型到架構設計圖資料庫設計編碼，迭代開發，後期維護期間有啥解決問題或者分析問題的巧妙思路問題看起來比較大，重在分享，勿噴

也算是幫別人debug不少了吧，有時候覺得這個稍微有一點通用的技巧。類似的思路不只限於代碼debug哦。

首先，冷靜下來，明確四點，

1. 現在的非期望的(或者說錯誤的)輸出是什麼。

2. 現在期望的輸出是什麼。

3. 現在的輸入有哪些。

4. 從輸入到輸出，整個流程大概是怎樣的，有哪些變數。

這四點建議按順序思考，一般的明顯的邏輯錯誤在思考第四點的時候就很容易發現了。當然一頭霧水的概率也還是很大的，這時候把debug想像成一次儘可能嚴謹的科學實驗，基本思路可以參照以下幾點。

如果你對整個系統比較熟悉的話，為了快速debug，先在腦內列舉一遍你能想到的所有可能導致問題的點，比如，網路是瓶頸，新代碼邏輯有問題，某個工具有問題。在腦內深刻記下這些點，或者列舉在紙上也行。把這些點按你直覺認為的可能性排序，或者是按照論證的難易程度排序，選取最可能或者最容易論證的點，對輸入/可變數進行修改論證。運氣好的話可以很快發現問題，運氣不好的話，恭喜，你發現了一個不太好調試的bug。這時候根據你做過的實驗，一點一點刪掉問題的可能性，也許這個過程中可以提出新的猜測。嘗試的時候盡量做到嚴謹，避免後續的判斷出錯。以及要勇於懷疑不可能出錯的部分，如果它是從輸入到輸出中比較重要的一環，做一下sanity test也是很有必要的。

另外還有個辦法是針對代碼的，逼近法。先拿一份目前掛掉的代碼，然後嘗試弄一份一定能跑通的代碼，可以在掛掉的代碼上大肆刪減，保留一定沒問題的主要模塊，或者從頭開始。然後，你有了兩份代碼，從可以運行的簡單代碼添加功能逼近目標代碼，這個過程可以快可以慢，但一定每次要儘可能確信代碼的正確性。慢慢的，你就能把錯誤片段逼近到一個角落裡，也許某個log某個watch就很顯而易見了。這個方法如果條件允許基本成功率是百分之百，有點級數逼近的感覺。

以上，歡迎找我debug (逃

腦內單步，配合關鍵位置的打出來的日誌，看腦內運行的結果和打出來是否一致……

謝邀，這我倒是經常出現啊。。。

經常是寫複雜邏輯的時候出事，寫著寫著寫暈了，這種時候就應該開始先整理代碼，對每一個表達式寫詳細的注釋。然後再寫詳細的Javadoc，把注釋組合起來。多輸出Log，百利無一害。記得封裝log類，release的時候一句注釋把所有log去掉。

為了讓自己輕鬆，可以在注釋裡面使用顏文字，賣萌，寫字元畫，或者寫點髒話進去。

我這習慣還把朋友帶壞了。這是一個學弟，和我一起寫Java玩的。

然後再用IDE的重構功能理一下類之間的關係。

然後運行幾次，思路就清晰了。

吶。

寫完之後順手找了一個，注釋是不是很萌

沒有捷徑。

越往後越資深越沒有奇葩方案。

我目前仍會出現的錯誤通常只有兩類。

Class 常見錯誤：{

Enum IDE環境中低級錯誤：

分號多了少了,

字母少了多了,

括弧未封閉；

Enum 非IDE環境中低級錯誤：

函數名記錯,

參數記錯,

輸入類型不匹配,

常見錯誤.IDE環境中低級錯誤[]；

}；

我的習慣是，設計方案和詳細設計先行，包括相關基類、指針、介面、函數、事件、方法及其它，並反覆檢查是否滿足設計預期，所有輸入輸出明確，並根據格式化方案先行書寫（自動化生成）所有關鍵邏輯的偽代碼。

自動化依賴症轉懶癌晚期無可救藥。

知道的越多奇葩的思路越少……

有個簡單的方法：出現 bug 之後把這個功能整個刪掉就好了

——7月31日更新新版 pokemon go 有感

首先應該避免常規性語法錯誤，需要一個好的ide，推薦phpstorm

然後勤寫單元測試，又可以過濾掉很多bug。

接下來說說我是怎麼調試的

1.簡單的var_dump+exit ，指哪打哪，適合上下文比較簡單的情況。

2.xdebug，配合phpstorm可以真正實現斷點調試，斷點調試的好處我就不多說了。

3.用strace命令跟蹤php進程所有的系統調用，一般可以知道是什麼原因卡住

換個思路來一發爐石，回來再看……

基本上是寫一點測試一點！有什麼不滿意的馬上修改！結合前面的看看自己訂的思路有沒有跑偏！