大家都知道，程序員是寫代碼的。但是現(xiàn)實情況卻是，寫代碼僅僅占了程序員日常工作的一小部分，大部分時間都在干嘛？ 解 Bug ！

當(dāng)然也有例外，比如初創(chuàng)公司的起始階段，比如一個全新的項目從無到有的過程，這些階段是程序員集中編碼階段，在 Coding 上花費的時間大概與 Debug 的時間相當(dāng)，或者略大于 Debug 的時間。

很多的公司，尤其是大公司，都有著非常成熟的產(chǎn)品，除了一些全新加嶄新的項目，程序員很少需要把軟件項目從 0 做起，都是在之前的版本上加以改進(jìn)，完善和迭代，同時還需要對老版本進(jìn)行維護(hù)。

所以，解 Bug ，很多時候，成了我們工作的重中之重。能不能快速地定位 Bug，解決 Bug，也是檢驗程序員新手與老手的一種方式。

那么，程序員老手是怎么解 Bug 呢？

其實都是有套路的，且聽我慢慢道來。

經(jīng)驗預(yù)判

測試人員報過來一個 Bug, 首先可以根據(jù)經(jīng)驗判斷一下，這到底是不是真的是一個 Bug。

千萬不要相信，測試說有一個 Bug，這真的就一定是個 Bug。

根據(jù)測試的 “Bug” 描述，先看一下：

1. 是不是測試用的軟件版本不一致？因為有的時候，這個 Bug 已經(jīng)在代碼庫中 Fix 了，但是測試人員并沒有及時獲取到這個信息，用的還是老的軟件版本。

2. 是不是測試工具的問題？遇到結(jié)果不對，并不一定是你軟件的問題，有的時候還有可能是測試工具的問題。

3. 是不是測試環(huán)境沒有設(shè)置對？測試環(huán)境的軟硬件是否匹配？軟件版本與測試工具之間是否匹配？環(huán)境變量與測試腳本設(shè)置對了沒有？測試用例用的對不對？

4. 是不是一個已知而又暫時不好解決的 Bug？比如這個 Bug 跟一個已知的硬件 Bug 相關(guān)，而這個硬件 Bug 一時半會也解決不了。

5. 是不是以前也遇到過類似的 Bug ? 而針對這個 Bug，已經(jīng)有了解決方案，但是還沒來及提交進(jìn)代碼庫。

6. 是不是別的開發(fā)人員已經(jīng)遇到過這個問題？ 可以適當(dāng)詢問一下比自己有經(jīng)驗的同事，以前有沒有遇到過這個 Bug。說不定這就是個別人已經(jīng)踩過的坑，那么知道了這個信息，你就沒有必要把這個坑再踩一遍。

猜測解決方案

這一點其實還是屬于經(jīng)驗預(yù)判。

當(dāng)你確定這真的是一個 Bug，而根據(jù) Bug 的描述，又可以八九不離十猜測出 Bug 的出錯原因的時候，可以試著修改代碼，把修改后的代碼讓測試人員拿去測試，看一下能否解決這個 Bug。

這一招是用在你對這個修改方案很有信心的時候?？梢员苊獗镜貜?fù)現(xiàn) Bug 的時間和精力消耗，因為有的時候，搭建個能夠復(fù)現(xiàn) Bug 的環(huán)境，還是很繁瑣的。

但是，切忌把你胡亂猜測的修改拿去讓測試人員測試，這一點對測試人員也不負(fù)責(zé)任。

本地復(fù)現(xiàn) Bug

憑著自己的經(jīng)驗，沒法一眼看出問題所在，那么就只有動手先把 Bug 在本地復(fù)現(xiàn)了再說吧。

前面說了，復(fù)現(xiàn) Bug，搭建測試環(huán)境，有的時候是一個很繁瑣的過程。涉及到軟件、硬件的匹配，測試工具的匹配，測試用例的匹配，還有各種環(huán)境的配置都要匹配。

所以這也是為什么我建議大家，不要一上來就急著搭建測試環(huán)境，復(fù)現(xiàn) Bug，可以憑自己的經(jīng)驗先行判斷的原因。當(dāng)然，一些簡單的很好復(fù)現(xiàn) Bug 的場合除外。

復(fù)現(xiàn) Bug， 除了搭建測試環(huán)境比較繁瑣以外，還有一個很令人頭疼的地方，那就是隨機(jī)性。

同樣的測試環(huán)境，只有在測試人員機(jī)器上 Bug 才會出現(xiàn)，而在你機(jī)器中，就是好的，你說是不是很邪門？ 你還別不相信，這種情況真的時有發(fā)生，鬼知道 Bug 經(jīng)歷了些什么！

隨機(jī)性 Bug，還有一個惡心的地方，就是不是 100% 可以重現(xiàn)。有的時候測試用例跑個 100 遍，Bug 才出現(xiàn)那么一兩次，程序員守在電腦前，等待個 Bug 重現(xiàn)，像是等待彩票開獎一樣，這心情，只有經(jīng)歷過的人才懂。

前面說這么多，只是想說明，復(fù)現(xiàn) Bug 有的時候，是多么繁瑣，多么痛苦。

開始調(diào)試

假如有幸復(fù)現(xiàn)了 Bug，那么接下來進(jìn)入正經(jīng)調(diào)試階段。

1. 查看 Log。大型軟件項目里面，都會有一些調(diào)試信息，會生成一些 Log，可以首先查看一下 Log 里面有沒有錯誤信息，這是排錯最直觀的方法。

2. 用調(diào)試工具單步跟蹤代碼進(jìn)行調(diào)試?？匆幌鲁绦蛟谶\行的時候，代碼里面發(fā)生了什么，跟蹤一下代碼邏輯執(zhí)行步驟，有沒有發(fā)生邏輯錯誤，是不是執(zhí)行到了異常代碼處理區(qū)，函數(shù)輸入和輸出值是多少，臨時變量，全局變量，結(jié)構(gòu)體的值又分別是多少。

3. 打印程序輸入、輸出參數(shù)、臨時變量，緩沖區(qū)和內(nèi)存空間。把這些變量存在文件中，用 Notepad++ 查看一下，是不是跟預(yù)期的一致，有沒有明顯錯誤的地方，需要的話，再進(jìn)一步查看它們的十六進(jìn)制碼。

4. 在任意需要的地方添加打印。有的時候，單步跟蹤不是很方便的情況下，或者在多線程情況下怕影響時序，可以在代碼里面逐行添加打印，把你想要的東西打印在文件里，這樣方便查看。

修改代碼

經(jīng)過前面的調(diào)試，你一定有了值得懷疑的目標(biāo)。接下來嘗試修改你懷疑的代碼段。

這個過程不是一蹴而就的，需要經(jīng)過不斷的修改、添加、刪除代碼。

1. 改正要害。經(jīng)過調(diào)試，假如你已經(jīng)確定了錯誤的原因，那么可以直擊要害，一下改正。

2. 增刪代碼。只是懷疑，還不確定，可以嘗試一下把你懷疑的代碼段注釋掉，看一下是不是就好了，接下來，進(jìn)一步縮小注釋范圍，直到聚焦到某一行代碼，那么這一行代碼應(yīng)該就是導(dǎo)致 Bug 的原因。但是這種還是比較理想的情況，有些問題比較復(fù)雜，你可以自己手動添加一些便于調(diào)試的代碼進(jìn)去。

這一過程本身需要不斷嘗試，改著改著，試著試著，就發(fā)現(xiàn)問題所在了。

解決問題

假如說前面的一切工作是為了發(fā)現(xiàn)問題，那么接下要做的是解決問題。

個人感覺解 Bug 的過程，最難的不是怎么解決問題，F(xiàn)ix Bug，而是前面定位 Bug ，找 Bug 的過程。可以說，找到了 Bug，解決方案就呼之欲出了。

定位到了 Bug 的原因，能自己解決的就自己解決，自己解決不了的申請資源，讓相關(guān)人員 （stakeholder）跟自己共同解決。

當(dāng)然，還是有些情況，發(fā)現(xiàn)了問題所在，Bug 并沒有那么好解決。

最后，修改了代碼，解決了 Bug，在 commit 之前，別忘記多測幾遍，看一下這個 Bug 是不是真沒有了，再做一遍回歸測試，看一看會不會引起新的 Bug。

多做幾遍本地測試，嗯！

做完測試，就開始走流程，提交代碼吧。

提交完代碼，老天保佑，集成測試不會有問題，先讓我忐忑幾天。