我曾經做了兩年大型軟體的維護工作，那個專案有10多年了，大約3000萬行以上的程式碼，參與過開發的有數千人，程式碼checkout出來有大約5個GB，而且bug特別多，open的有上千，即使最高優先順序的showstopper也有上百。

分享下我的debug的經驗

1.優先解決那些可重現的，可重現的bug特別好找，反覆除錯測試就好了，先把好解決的幹掉，這樣最節約時間。

2.對於某些bug沒有頭緒或者現象古怪不知道從哪裡下手，找有經驗的同事問一下思路，因為在那種開發多年的大型系統裡，經常會反覆出現同樣原因的bug，原因都類似，改了一處，過一陣子另外一處又冒出來，而且無法根治。

比如：我那個系統裡有個特別危險的API，介面引數比較難用，一旦有人用錯了某些情況下就會出詭異的現象，解決很簡單，找到呼叫這個API的地方把呼叫方式寫對就好了。為什麼不根治呢？因為要保持相容性不能改介面了。Windows系統裡就好多這種爛API。

問下老員工吧，說不定他們都遇到過好多次了。

3.放大現象，有些bug現象不太明顯，那麼就想辦法增大它的破壞性，把現象放大。這只是個思路，具體怎麼放大隻能根據具體的程式碼來定。

比如：美劇《豪斯醫生》裡有一集，懷疑病人心肺有問題，就讓病人去跑步機上跑步，加重心肺負擔，從而放大症狀。

4.二分法定位，把程式邏輯一點點註釋掉，看看還會不會出問題，類似二分查詢的方法，逐步縮小問題範圍。

5.模擬現場，有時候我會問自己，如果我要實現bug描述的現象我要怎麼寫程式碼才行？

比如：我遇到一個死鎖問題，但是檢查程式碼發現所有的鎖都是配對的，沒有忘記解鎖的地方，而且鎖很簡單就是一個普通的臨界段，保護幾行賦值語句而已。這樣的程式碼怎麼寫才能讓他死鎖呢？

我想如果讓我故意製造這樣一個現象，只有在上鎖的時候強制殺掉執行緒了。

既然這樣就可以去看看有誰強殺執行緒了沒有。

6.製作工具，針對某些bug編寫一些除錯輔助工具。

比如，我那個系統沒有完善的崩潰報告，雖然也有dump，但是分析出來的callstack經常不準。於是我為解決崩潰問題編寫了個工具，會自動掃描程式碼，在每個函式入口和出口插入log，以此來定位崩潰點。

7.掩蓋問題，雖然這樣做有點不厚道，但是有時不得不這麼做。有些bug找不到真正的root cause，但是又要在規定時間內解決，那麼我們就可以治療症狀而不去找病因。比如用try catch掩蓋一些奇怪的崩潰。不到萬不得已不要這麼幹，未來可能會付出更大代價。

我在做這份工作的時候也在追美劇《豪斯醫生》，豪斯大叔解決病症的思路和debug差不多，對我很有啟發。如果你也想在IT行業拿高薪，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來我們的JAVA交流群：240448376，群裡網盤也有各種免費資源共享，不懂的知識點可以問群主管理員。期待你的加入。

作者：姚冬

來源：知乎