我曾經做了兩年大型軟體的維護工作，那個項目有10多年了，大約3000萬行以上的代碼，參與過開發的有數千人，代碼checkout出來有大約5個GB，而且bug特別多，open的有上千，即使最高優先順序的showstopper也有上百。分享下我的debug的經驗。
bug代碼如何找
1.優先解決那些可重現的
可重現的bug特別好找，反覆調試測試就好了，先把好解決的幹掉，這樣最節約時間。
2.問下老員工
對於某些bug沒有頭緒或者現象古怪不知道從哪裡下手，找有經驗的同事問一下思路，因為在那種開發多年的大型系統里，經常會反覆出現同樣原因的bug，原因都類似，改了一處，過一陣子另外一處又冒出來，而且無法根治。
比如：我那個系統里有個特別危險的API，介面參數比較難用，一旦有人用錯了某些情況下就會出詭異的現象，解決很簡單，找到調用這個API的地方把調用方式寫對就好了。為什麼不根治呢？因為要保持兼容性不能改介面了。Windows系統里就好多這種爛API。問下老員工吧，說不定他們都遇到過好多次了。
3.放大現象
有些bug現象不太明顯，那麼就想辦法增大它的破壞性，把現象放大。這只是個思路，具體怎麼放大只能根據具體的代碼來定。比如：美劇《豪斯醫生》里有一集，懷疑病人心肺有問題，就讓病人去跑步機上跑步，加重心肺負擔，從而放大癥狀。
4.二分法定位
把程序邏輯一點點注釋掉，看看還會不會出問題，類似二分查找的方法，逐步縮小問題範圍。
bug代碼模擬現場
有時候我會問自己，如果我要實現bug描述的現象我要怎麼寫代碼才行？比如：我遇到一個死鎖問題，但是檢查代碼發現所有的鎖都是配對的，沒有忘記解鎖的地方，而且鎖很簡單就是一個普通的臨界段，保護幾行賦值語句而已。這樣的代碼怎麼寫才能讓他死鎖呢？我想如果讓我故意製造這樣一個現象，只有在上鎖的時候強制殺掉線程了。既然這樣就可以去看看有誰強殺線程了沒有。
總之，bug代碼給大家簡單的介紹了一些，希望大家多看看。