沒有解不了的bug，只有追不到的女神
大家好，我是良許。
我們程序員的成長史就是與bug的斗爭史，每天重復(fù)著寫bug、解bug。俗話說：沒有解不了的bug，只有追不到的女神。
不僅菜鳥不斷埋雷，老司機(jī)也在創(chuàng)造bug，只是頻率略低。
當(dāng)然了，即使你是老司機(jī)，代碼寫的溜溜的，在團(tuán)隊(duì)作戰(zhàn)時(shí)也難免被團(tuán)隊(duì)成員拉下水，在特殊時(shí)期被迫上陣測試bug。正所謂，不怕神一樣的對手，就怕豬一樣的隊(duì)友。
既然bug是不可避免的，大神的升級之路也少不了它的豐功偉績，那當(dāng)程序出現(xiàn)bug后，要如何進(jìn)行調(diào)試。且看我十招降龍十八掌解Bug法，比追女神的方法更管用。圖片
首先，調(diào)整心態(tài)
人人都會出bug，bug是無法避免的，所以千萬不要覺得，我出現(xiàn)了bug，就說明我比較菜(雖然自己確實(shí)比較菜)。
雷軍，馬化騰，李彥宏，張小龍，他們都寫過無數(shù)的bug，出險(xiǎn)bug是一件很正常的事。千萬不要有太重的心理負(fù)擔(dān)，平常心對待即可。
其次，想辦法復(fù)現(xiàn)bug
如果自己復(fù)現(xiàn)不了的話，可以找測試人員幫忙。如果bug能夠穩(wěn)定地復(fù)現(xiàn)，那么幾乎可以斷定，這個bug是肯定可以解決的。
最讓人頭疼的是偶然出現(xiàn)沒辦法復(fù)現(xiàn)的bug，如何解決這種神奇的bug我們等下再說。
第三，仔細(xì)分析現(xiàn)象
對照需求文檔，看看程序正確的運(yùn)行應(yīng)該是怎樣的狀況，再對比bug出現(xiàn)的現(xiàn)象，我們一般可以大致定位出來是哪個部分出現(xiàn)了問題，再對那個部分進(jìn)行深入分析。
第四，查看日志文件
日志文件是非常重要的一個文件，記錄了程序進(jìn)行過程中輸出的各種結(jié)果，同時(shí)也記錄各種各樣的報(bào)錯信息。所以你分析報(bào)錯信息，再結(jié)合報(bào)錯點(diǎn)上面及下面一些正常的log，一般也可以定位到對應(yīng)的代碼位置，甚至直接就可以解決bug了。
這就要求我們平時(shí)在寫代碼時(shí)，一定要多留個心眼，把可能出錯的地方多寫一些log，特別是if...else，try...exception，這類程序異常運(yùn)行的地方多加一些log。
雖然寫這些log的時(shí)候可能會多花點(diǎn)時(shí)間，但在代碼出現(xiàn)bug的時(shí)候可以給你省下很多調(diào)試的時(shí)間的。
第五，網(wǎng)絡(luò)上查找解決方法
其實(shí)很多bug也有其他程序員碰到過，所以如果你實(shí)在分析不出原因的話，直接網(wǎng)上搜索解決方案。推薦google，stackoverflow，bing，最后再用百度。
搜索時(shí)，建議盡量用英文，這樣搜出來的結(jié)果會更多，并且不少會是非常詳細(xì)的解答，非常有助于bug的解決。
第六，注釋法
如果你實(shí)在沒有思路，那可以采用注釋法來排查。所謂的注釋法，就是你把你寫的類、函數(shù)、模塊，等等你認(rèn)為有可能出現(xiàn)這個bug的部分，一個個依次注釋掉。
每注釋一部分，編譯運(yùn)行，看看bug有沒復(fù)現(xiàn)，有復(fù)現(xiàn)的話繼續(xù)再注釋其它部分，直到bug不再出現(xiàn)。這樣就可以確定bug出現(xiàn)在剛剛注釋的代碼里，再慢慢把注釋的代碼打開，就慢慢縮小了范圍，然后就能排查出問題了。
這個方法是當(dāng)年我的一個主管教我的，我覺得非常實(shí)用，現(xiàn)在分享給大家。
第七，斷點(diǎn)調(diào)試
這應(yīng)該是很常見的一種調(diào)試方法了。你可以在代碼可能出錯的地點(diǎn)打上斷點(diǎn)，然后再運(yùn)行代碼，看看程序會在哪一行出錯。這種方法簡單實(shí)用，效率也非常高。
第八，增加日志
對于一些不方便進(jìn)行斷點(diǎn)調(diào)試的場合，比如說我所從事的Linux應(yīng)用開發(fā)的場合，一般我們寫完程序編譯后就直接丟到Linux平臺上運(yùn)行，如果要調(diào)試的話需要用到gdb，但很不方便。
所以對于我個人來講的話，我?guī)缀鯖]用過斷點(diǎn)調(diào)試，我用的方法就是在代碼里可能出錯的地方，人為地再增加幾個log，或者把一些對應(yīng)的變量的值用log打出來。然后通過已有的log及新增的這些log，就可以排查出來問題點(diǎn)了。
這種方法雖然說不是很高效，但用這種方法一般要先分析代碼，再打相應(yīng)的log，可以鍛煉在大腦里直接運(yùn)行代碼的能力，久而久之也會提升代碼水平，后面調(diào)試的速度也會越來越快。據(jù)說，大神都是偏愛這種調(diào)試方法。
第九，code review
如果你上面的方法都沒辦法解決bug，或者你的bug根本就沒辦法復(fù)現(xiàn)，那么你就可以組織一場code review，讓組內(nèi)的成員一起來找茬。一個人的力量有限，但一群人加起來就會有無窮的力量了。通過一群人來群毆你的代碼，很可能就會找到這個bug的根因了。
第十，請教老程序員
俗話說，不懂就要問。所以，你如果實(shí)在解決不了bug的話，可以去請教組里的老程序員。老程序員一般經(jīng)驗(yàn)比較豐富，他們有可能根本不需要調(diào)試，一眼就看出你的問題點(diǎn)。所以，平時(shí)有事沒事一定要跟老程序員搞好關(guān)系，到時(shí)候請他們幫忙的時(shí)候就好開口了。
但是，千萬不要太依賴?yán)铣绦騿T，即使他們幫你解決了問題，你也一定要自己去想一下，他們是怎么解決你的問題的，使用了什么方法什么技巧?只有這樣做，你的技術(shù)才會得到提升。
最后，再推薦一個國外很流行但國內(nèi)很小眾的方法，小黃鴨調(diào)試法
所謂的小黃鴨調(diào)試法，并不代表小黃鴨會幫你解bug，而是你在調(diào)試代碼的時(shí)候，手拿一只小黃鴨，然后詳細(xì)跟小黃鴨講解你寫代碼的思路，以及每一行代碼的意義。
這樣講著講著，突然就會靈光一現(xiàn)，找到問題點(diǎn)了。這種方法看起來有點(diǎn)傻，有誰會對一個玩偶嗶哩叭啦講代碼，所以我估計(jì)這也是小黃鴨調(diào)試法在國內(nèi)流行不起來的原因。
如果你覺得這樣很傻的話，可以拉一個同事過來，向他講解代碼?；蛘吣阋部梢宰匝宰哉Z，講著講著，你就可能找到解決方法了。
好了，以上就是我給大家推薦的幾種bug解決方法。這些方法都是非常實(shí)用的，如果一種方法行不通的話，可以用其它方法來解決，甚至使用多種方法一起來解決問題。
