老程序員解Bug的通用辦法

程序員在很多人的印象里是一份嚴(ku)謹(bi)的職業，也是一個被搞怪吐槽樂此不疲的職業，程序員們面對複雜的代碼敲打電腦時連眉頭都不會皺一下，但是有一個詞卻是他們痛苦的根源，它就是Bug。

記得剛畢業入行時，我們老大派給我和另外一個新來同事的第一件事就是修Bug，要不是在學校敲過幾年代碼，還真不知道如何下手！和我一起進公司的另外一個同事完全就是以「看戲者」的身份，看我搞了3個月，直到我們轉正。實際上，很多時候，讓一個新人去調Bug，真的是勞財傷命，浪費時間。尤其是一些大型系統的複雜性Bug，讓一個新人去搞定，很多時候，這無異於在開一個大玩笑！這種決定往往取得的結果不是加快了項目的進度，反而會讓這些年輕人備受打擊，有時甚至會讓新人們對人生產生懷疑。這絕對不是一個老程序解決Bug的套路。有人可能要反駁，我不能讓他藉助調Bug，了解下系統不行嗎？對於有這種想法的，我只能說，你太高估別人了，你讓一個有2,3年開發經驗的人，去熟悉一個大型系統也不是件輕鬆的事情。若非天賦很高，那麼很可能導致我們的新人，在進入公司後的實習期，處於緩慢進步甚至進步停滯的狀態，天天盯著開發計劃表裡的Bug，丈二和尚摸不著頭腦，不知所措，這種狀態不管對公司還是個人發展都不利。鄙人認為合理的方式是，給新人把整個系統的結構粗講一遍，再給分配一些簡單的模塊去開發比較好。

當然我們處理bug不光是為了自己，很多時候是因為被測試和領導盯著：

不同人對bug的反映

當程序員找 Bug 的時候

程序員調 Bug 的感覺，就是這樣的一波未平，一波又起

叫新手程序員幫忙改 Bug

牛 X 程序員和 Bug 之間的 PK

開發人員在演示中如何隱藏 Bug

千萬不要當程序員面說有bug

對於新手程序員而言，在複雜代碼中找BUG是一個難點。下面我們總結下老從程序員解Bug的通用套路，希望對大家有幫助。

1.IDE調試

根據項目特點和語言特點選擇一個最合適的IDE，由於本人是做C++出身，最喜歡用的莫過於Visual Studio 了，這款微軟開發的IDE，自從研發出來，就被稱為宇宙第一編譯器，能編譯調試C/C++、C#、F#、Python、JavaScript、Qt、iOS等多種語言的開發。目前的VS2017還原生支持遠程跨平台的軟體開發，這無疑給我們常年奮戰在linux/Unix黑匣子開發環境，使用G++調試的C/C++程序猿們帶來了福音。

2.重構大法。

如果你發現無論如何也找不到BUG，而且代碼只是複雜，本身不是很長，直接重寫代碼吧!重構大法是解決爆炸性bug的絕招。

3.printf大法

大家都說printf大法（也稱cout大法）好，我也這麼覺得！把需要驗證的參數列印出來，不僅直觀，而且方便調試。

4.日誌大法

日誌大法，法力無邊。一個成熟的系統少不了日誌模塊，懂得和善於使用日誌大法調bug的同學，恭喜你，你已經步入中級程序員的行列。

5.小黃鴨調試法

小黃鴨不懂程序，所以我們可以向他解釋每一行程序的作用，以此來激發靈感。

6.二分定位法

把程序邏輯一點點注釋掉，看看還會不會出問題，類似二分查找的方法，逐步縮小問題範圍。

7.模擬現場法

模擬現場，有時候我會問自己，如果我要實現bug描述的現象我要怎麼寫代碼才行？比如：我遇到一個死鎖問題，但是檢查代碼發現所有的鎖都是配對的，沒有忘記解鎖的地方，而且鎖很簡單就是一個普通的臨界段， 保護幾行賦值語句而已。這樣的代碼怎麼寫才能讓他死鎖呢？我想如果讓我故意製造這樣一個現象，只有在上鎖的時候強制殺掉線程了。既然這樣就可以去看看有誰 強殺線程了沒有。

8.製作調試工具

此方法在很多大廠比較常見，一個是快速迭代的要求，一個是大廠的通用框架比較成熟，當然工具的適用性比較強。

9.優先解決可重現的bug

可重現的bug，優先解決，多調試測試幾次，把容易解決的bug先解決掉，亦可以減少bug數量，也可以減少干擾。

10.放大現象。

有些bug不是很明顯，那麼就想辦法增加他的破壞性，把現象放大，這在我們的系統壓力測試時會經常遇到一種方法。千萬別覺得自己的系統就幾千日活，就把壓力測試壓得很低，結果，實際上線時，系統壓力過大宕機的情況不在少數，這種問題很多大廠也出現過，還記得有一年搶紅包，搶了點不開的事嗎？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！