程序員修煉之如何提高Debug效率
本文轉(zhuǎn)載自微信公眾號「 跨界架構(gòu)師」，作者Zachary 。轉(zhuǎn)載本文請聯(lián)系 跨界架構(gòu)師公眾號。
大家好，我是Z哥。
可以不夸張地說，程序員可能有一半的時間都在修bug。雖說，根據(jù)28原則大部分bug都可以在搜索引擎上搜到(業(yè)務(wù)性bug除外)，但是往往剩下的那20%bug會花費我們80%的時間。
雖然解決這個問題最好的是方式減少產(chǎn)生bug，但是再怎么減都不可能減到0，我們還是有必要提高自己Debug的效率。
因為在Debug方面，水平高的人可能在效率上能領(lǐng)先至少一個數(shù)量級。我在這個行業(yè)從業(yè)將近9年，我見過太多這樣的案例了。網(wǎng)上也流傳過一個傳播度很高的案例，有一個阿里內(nèi)部的團隊排查好幾天未果的一個問題，去請教多隆大神，分分鐘就搞定了。
很多人的Debug能力之所以長期止步不前，在我看來主要原因是兩個。
- 一是對IDE的功能不夠了解，只會用平時一直在用的基礎(chǔ)功能。
- 二是沒有掌握一個合理的Debug思路，屬于“運氣型”選手。
不同的編程語言，主流的IDE都不同，所以我主要就第二點展開說說我的經(jīng)驗。
有些經(jīng)驗的程序員都知道，Debug的過程最重要的不是怎么修復(fù)bug，而是怎么找到產(chǎn)生bug的地方。所以，下面要講的思路主要也是圍繞排查bug相關(guān)。
縮小問題范圍
縮小問題范圍的方式有很多，本質(zhì)上其實是從當時的環(huán)境中找到與問題更高相關(guān)的變量。最常見的變量主要在以下這些：
- 運行環(huán)境
- 所操作的數(shù)據(jù)
- 瀏覽器
- 對應(yīng)的源碼版本
建議你先從這幾個變量進行驗證。然后再弄清楚上一次正常操作與當前出現(xiàn)bug的操作之間的這段時間發(fā)生過什么。大多數(shù)情況下，問題的根源就藏在這里面。那種潛藏很久才遇到的疑難問題，畢竟是少數(shù)。
提煉并優(yōu)化每一類bug的標準處理流程
工作中很多流程需要SOP，在修復(fù)bug這件事上也可以這么做，如此可以將每一次修復(fù)一個疑難bug的過程給沉淀下來。
常見的bug類型主要有4類：
- 輸出與預(yù)期不符
- 程序報錯
- 程序明顯響應(yīng)慢
- 程序crash
每一類都有適合它們的排查方式，如果你總是用同一個套路去排查這4類問題，效率自然不會太高。
01 輸出與預(yù)期不符
這種bug最頭疼，為什么呢?因為它不像那種異常、報錯的bug，有堆棧信息，可以快速縮小排查范圍，甚至直接定位到產(chǎn)生的地方。
那么怎么辦呢?如果這個問題在測試環(huán)境，那么最簡單，直接單步調(diào)試走起，這個時候如果對IDE的調(diào)試工具掌握得越深入，效率也會越高，比如條件變量、多線程調(diào)試等等。
這里多說一句，強烈建議每個人掌握自己所用IDE的條件變量和多線程調(diào)試這兩種方法，在當前的大環(huán)境下，整個軟件開發(fā)領(lǐng)域的大型項目和多線程運用都比幾年前高得多。
如果沒法單步調(diào)試的情況，那么只能通過多打一些日志，來達到接近單步調(diào)試的效果。不過這點需要你做一些預(yù)判，在一些代碼分支、可疑位置打上日志即可，畢竟編寫記錄日志的代碼也需要時間不是。
02 程序報錯
這種bug對有些經(jīng)驗的程序員來說是最簡單了，因為直接告訴了你產(chǎn)生異常的代碼位置。
但是對新手就不同了，很多新手會拿著描述異常的一堆文字去搜索引擎搜，比如(NullPointer Exception)，搜出來N多文章，一篇一篇看下來并嘗試都發(fā)現(xiàn)不能解決自己的問題，其實就是由于自己還沒習慣于去看堆棧信息。因為別人的NullPointer Exception和你的NullPointer Exception產(chǎn)生的原因并不一樣。
堆棧信息中記錄了整個調(diào)用鏈路，所以通過這里你可以看到完整的方法調(diào)用順序。
不過值得提醒的是，在日常編寫的代碼的時候，千萬不能隨意的try catch代碼塊，然后throw一個new exception，因為這會導(dǎo)致堆棧信息不完整。
03 程序明顯響應(yīng)慢
這種問題一般是在產(chǎn)生資源競爭，或者資源緊張的時候發(fā)生。排查他們的難度也比較高。
如果說前面兩類問題中，高水平和低水平的區(qū)別只在于解決效率的高低上，那么這個問題對低水平的程序員們來說可能是不管花多少時間都找不到問題的原因。
不過不要緊，我建議你以后遇到這種情況，優(yōu)先從以下這幾個指標入手。
- TCP連接數(shù)
- 內(nèi)存占用率
- 線程數(shù)
對于TCP連接，你身邊得常備一份netstat命令手冊，然后敲入命令，分別查看連接數(shù)是否接近到了65535?TIME_WAIT、CLOSE_WAIT狀態(tài)的連接是不是過多?
大多數(shù)情況下，TCP連接相關(guān)的問題主要就是兩個：
- 連接使用完后未及時釋放
- 針對高頻調(diào)用未使用長鏈接，而使用了短鏈接。此時一旦下游服務(wù)響應(yīng)慢就會快速打滿65535個連接。
對內(nèi)存問題的分析，主要是就是通過分析GC來進行，主要關(guān)注是否有什么類型的對象占用內(nèi)存過大了。如果存在過大的情況，主要原因是以下兩個：
- 某個大對象應(yīng)該是共享使用的，在代碼里不小心寫成了每一個實例各自一份。
- 某個對象分配的時候不小心帶上了static關(guān)鍵字，導(dǎo)致GC一直無法回收為其分配的內(nèi)存。
不同的編程語音有不同的GC分析工具，需要熟練掌握。
對線程的分析，和TCP連接類似，主要集中在線程的數(shù)量和狀態(tài)上。線程并不是數(shù)量越多、性能就越好。數(shù)量越多，可能花在線程之間的上下文切換上的時候就比實際執(zhí)行代碼邏輯還要多。
另外，是不是有大量線程blocked或者deadlocked了?隨便挑其中一個線程，分析其當前的堆棧信息，就是問題所在。
04 程序crash
導(dǎo)致crash的主要原因有兩點。
- 是由于前面提到的原因3未及時察覺，導(dǎo)致程序運行直到資源耗盡，由操作系統(tǒng)干預(yù)強行終止運行。
- 代碼中存在未捕獲的exception。
第一點參照原因3的處理方式。
第二點就很簡單了，在代碼的最外層做一個大大的try catch，然后打上日志將堆棧信息記錄下來，發(fā)布到線上，自然就能看到是那里出現(xiàn)的問題，然后轉(zhuǎn)到原因2的處理方式。
最后，提高Debug能力必須要多實踐。所以，我是非常建議你在條件允許的情況下，勇敢地去挑起排查線上疑難雜癥的任務(wù)，甚至并不是你直接負責的功能模塊。
可能在外人看來你在幫別人“擦屁股”，但這會讓你的Debug能力得到明顯的提升，并且容易形成對你的依賴，讓你越來越強。
好了，總結(jié)一下。
這篇呢，Z哥和你分享了我對提高Debug效率這件事的看法。
想要提高Debug的效率，一是要對IDE工具有熟練的了解，知道一些高階的使用方式。二是要對Debug有一套自己的思路。
對于第二點，我建議的步驟是：
- 縮小問題范圍
- 提煉并優(yōu)化每一類bug的標準處理流程
Bug主要分為4類，我在文中給出的思路也區(qū)分了這4類：
- 輸出與預(yù)期不符
- 程序報錯
- 程序明顯響應(yīng)慢
- 程序crash
希望對你有所幫助。
在我看來，Debug是一件很好玩，也很有成就感的事情，不亞于設(shè)計一個項目的框架。而且Debug還能讓你真正地體會到什么是“魔鬼藏在細節(jié)里”。
