其實程式設計師最關鍵的技能遠不止編碼能力，架構思維、底層知識的深度等等，同樣很重要。
在這些能力中，最容易被人忽視卻很重要的能力是：debug能力。甚至我認為：debug能力遠比編碼能力更重要。很簡答，大家可以觀察下自己的團隊，最優秀的程式設計師一定會承擔很多疑難症的排查和解決。
曾經在360帶幾十人技術團隊，同時研發幾條業務線。參與過的產品，日活過千萬的有一款，過百萬的有三款。
這個過程中各種稀奇古怪的bug見過不少，也一一解決了(不然估計就要滾蛋)。
1.日誌log盡可能詳盡
程式設計領域流傳著一句話：必現的bug，都不是bug。
因為好復現，就容易解決，**一直跟下去，或者看看堆疊資訊，很快能定位問題。
真正困難的是偶現bug，甚至那種概率千分之幾，但後果嚴重的bug。解決他們就需要詳細的日誌log，尤其是關鍵點上的資訊，非常重要。
2.google要用好
程式設計師+google=好的程式設計師，這句話真的沒錯，很多技術bug，當你毫無頭緒之際不妨google下，可能不少人遇見過。
當然，最關鍵的是搜尋的關鍵字，這取決於你對bug現象的描述，越言簡意賅搜尋到的資訊反而越多。
3.排除法
這個方法說實話不提倡，但很多時候實在束手無策之際不妨用用，用法也很簡單，當你不確定哪一塊新增**引入問題，就嘗試注釋一部分**看看程式是否ok。
不行再換另一部分**注釋掉，很快你就可以縮小bug的查詢範圍，進而定位問題。
4.模擬使用者環境
可以採用一些工具來模擬前端或者後端，製造假資料、假操作。有了這些工具之後，把你懷疑可能出問題的情況模擬一遍，觀察是否會出問題。
其次，遇見一些極端情況，比如懷疑是多執行緒/多程序死鎖，那不妨在某個程序/執行緒寫個死迴圈看看bug是不是就出現了，當然做這種操作千萬千萬別給忘記了，提交了，那就完犢子了。
5.記錄曾經解決過的bug，並簡歷索引
其實很多bug會變著花樣反覆出現，俗話說好記性不如爛筆頭，把解決過的問題記錄下來，並且做好索引，下次遇見可能相同的問題，先檢索一遍，搞不好就找到答案了。
6.多看官方文件
特別是引用了第三方**或者是開源**導致的問題，官方文件對應的部分反覆看看，可能問題就解決了。
7.引入工具，放大問題
比如很多執行緒注入的工具，你開啟後，但凡是一點點依賴執行緒順序的bug都會從偶現變為必現。
這個相當於主動把**執行環境變成地獄模式，比如你的乙個執行緒的結果依賴於另乙個執行緒的輸出，但你忘記加同步**了，不過大部分情況另乙個執行緒執行都飛快，但有些機器就不好使了。
這個時候加入這種工具，它直接讓某些情況下另乙個執行緒執行速度變慢(我猜大概率是加了個sleep(1000))，結果你的程式就崩潰了，崩潰堆疊直接開啟，迅速定位，問題解決!
8. 製作工具，針對某些bug編寫一些除錯輔助工具。
比如，某些系統沒有完善的崩潰報告，雖然也有dump，但是分析出來的callstack經常不准。完全可以為解決崩潰問題編寫了個工具，自動掃瞄**，在每個函式入口和出口插入log，以此來定位崩潰點。
以上8點，都是在實戰血淋淋的過程中總結出來的，希望對大家有幫助。
還沒關注的小夥伴，可以長按關注一下：
如何成為優秀程式設計師
1，文件習慣 文件是乙個軟體系統的生命力。乙個公司的產品再好 技術含量再高，如果缺乏文件，知識就沒有繼承，公司還是乙個來料加工的軟體作坊。作為 程式設計師，必須將30 的工作時間寫用於技術文件。沒有文件的程式設計師勢必會被淘汰。2，模組化思維能力 要想成為乙個優秀的程式設計師，他的思想不能僅僅只在侷...
如何成為優秀的程式設計師
1 學習應該從基礎打起，不要一開始就嘗試最高深的技術。2 每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。3 對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的難點提煉出來，向高手請教。3 不要指望書本和行家能...
如何成為強大的程式設計師
aaron stannard 是新創公司 markedup 的 ceo，他最近花費大量時間僱傭 評估很多不同的程式設計師，並和他們一起協作。在這個過程中他發現並總結了十種程式設計師無法意識到自己潛力的原因，意在讓更多程式設計師發掘出自己的潛力，從而成為強大的程式設計師。aaron 提到，他的公司中所...