增強debug能力來提升工做效率

以個人觀點來看：作出一個業務功能是件很簡單的事，作好則有難度，高效的作好則是難上加難。拋開前期的架構設計、技術方案的制定不談，單單是寫好代碼這一階段就給咱們每一個人帶來了不一樣程度的挑戰。以前還寫過一篇關於代碼編寫階段的文章《提升工做效率的工具「類」》，下面我就主要從代碼debug的角度來談談個人見解。

---

• 儘可能寫代碼時避免bug，減小調試
  對於任何問題，先以預防爲主。在團隊中經常能夠碰見這樣的同事，代碼寫的很是快，但是天馬行空的代碼以後卻讓本身陷入了無盡debug的沼澤。我會給這樣的同事建議：多花點時間作好代碼結構的設計，寫代碼時常常進行review，另外就是老生常談的細心。

• 利用好IDE和工具
  經常聽到這樣的見解，用vim，emacs的看不起用IDE的，以爲vim..就是銀彈，無論什麼語言，什麼平臺只要你問他什麼IDE最好，他必定回答你vim..。固然不排除有能把vim..用的出神入化的人，其餘的大多數是在裝X吧。你要記住，你的目標是完成工做，不是顯示本身多高端，多牛X。gdb同理。合適的IDE有不少好處：錯誤提示、代碼補全、豐富的替換查找、各類關聯跳轉，固然若是你不嫌麻煩，不怕不許確也能夠對vim進行配置來實現相同的效果，但請先看看這篇文章再作決定《編輯器與IDE》,以上幾個IDE帶來的好處不正好對咱們上面提的「儘可能避免bug」有很正面的意義嘛。另外，IDE集成的debug界面友好也強大（用過gdb的朋友確定知道），斷點，step over，step into，內存變量，調用堆棧...簡直就是debug神器，至少我寫程序讀程序的標準步驟就是依靠這幾步。(說點誇張的，可是我還確實遇到了很多人包括一些不少年工做經驗的工程師居然從沒有用過斷點調試，徹底靠着printf行走江湖，個人「驚訝」如滔滔江水啊...)，在調試中其餘工具的使用也可使debug事半功倍，好比內存泄露的檢測工具，還有進行網絡編程時的各類工具（wirshark，netcat，tcpdump...)

• 程序輸出日誌
  我認爲日誌系統也應該是一個程序的標準組成部分。其最大用處就是幫助咱們來梳理程序行爲，準肯定位bug。有些朋友要問了，我能夠用IDE來調試觀察啊，問題是不少bug並非在你寫代碼測試時發現的，是在發佈以後的用戶那裏，傻眼了吧？還有很重要的一點，多線程問題、還有一些依賴於具體系統環境或時間環境的問題是很難復現的，此次抓不住你就等着一直提心吊膽吧。我在工做中一直使用Apache的log4X系列，又一個強大的神器。但在有些環境下用不了log4X，好比在有些對程序所佔空間大小很敏感的的嵌入式環境（log4cxx的動態庫較大），你徹底能夠本身利用標準輸出封裝相應的日誌系統，而後運行時作好定向輸出工做就好。

• 崩潰轉儲
  崩潰這種fatal級的大bug最讓咱們頭疼，在C/C++中十有八九是內存違例（段錯誤）形成的。這種bug和多線程問題同樣也是最難找的，因此咱們必定要儘量的準肯定位抓住它，最有效的辦法就是利用內存轉儲文件。在linux平臺下開啓這個選項後利用gdb core就能夠進行定位分析。windows平臺下較麻煩，得本身實現內存轉儲功能，推薦你們一個工具類mini_dump,一旦程序崩潰就會產生dump文件，以後使用windbg調試便可。

• google
  不少bug本身想了各類辦法也定位不了或者沒法fix，這時你就得請教google大神了。儘可能別用百度，若是中文搜索條目不多或沒有，換成英文搜索，也許會有更多的收穫。

• 問
  我給個人團隊成員提了這麼一個建議：若是一個問題你本身嘗試了，也google了，可是沒法解決。一旦超過一個小時耗在這個問題上請大膽的尋求外部幫助吧，問團隊中經驗較豐富的成員，也許他曾經遇到過，也許他會給你提供好的建議或者思路。

• 深刻學習
  其實這點排在最前面比較合適，先去深刻學習再去作相應的工做。可是咱們實際工做中偏偏相反，每每是遇到了問題再去深刻學習，我以爲不少bug的造成是咱們對知識的只知其一;不知其二甚至一無所知形成的，咱們要儘可能拋棄那種臨時抱佛腳式的學習，而是要在本身的職業生涯中持續不斷學習，深刻學習。

以上就是我對提升debug能力的一些見解和實踐。