老程序員解決bug有哪些通用套路？

1 代碼本身沒有問題，但每次執行到那一行就是報錯，最後跟蹤出來是內存溢出的問題；

2 代碼本身沒有問題，但因為對API不熟悉，在使用的邏輯上有問題，導致了莫名其妙的現象，比如Android的AsyncTask；

3 測試定義為隨機問題，只能通過走讀日誌和測試描述的步驟來推理解決；

4 因為列印導致耗時嚴重影響性能的問題；

5 單步調試無法定位到問題的原因（多數是因為多線程的原因），只能通過列印解決；

6 因為編碼上的疏忽大意，跟蹤很久結果發現是非常低級的錯誤；

7 正常使用沒問題，但頻繁調用某個方法導致代碼重入的問題；

8 沒有足夠的日誌，只能通過用戶描述的現象和代碼推理來分析程序的邏輯是否有問題；

9 其他同事找我協助解決問題，對他們的代碼完全不熟悉，只能通過分析和排除法來解決；

因為遇到的多數問題不管解決過程多曲折，基本都能得到解決；再加上豐富的寫bug和解bug經驗，自然而然形成了一套屬於自己的解決問題的套路，正好分享這方面的內容，將自己的套路總結了下：

一 解決問題的流程：了解問題定位問題分析問題解決問題驗證問題

在解決問題之前一定要弄清楚具體的問題是什麼，看到過太多糾結了很久但發現自己所解決的問題並不是測試描述的問題的情況了；

解決bug最耗時的地方在於定位問題和分析問題，這個可以藉助「二」中介紹的幾種方法。

這套流程不僅僅適用於解bug，同樣適用於解決工作和生活中的各種問題。

二 解決問題的方法（排名分先後）：1 藉助搜索引擎：

遇到有明顯的異常信息，且自己並不熟悉為什麼異常時，最高效的解決方法是藉助搜索引擎，這裡的搜索引擎一定是谷歌，不是百度；藉助搜索引擎能解決工作中的大部分bug，你要相信，全世界這麼多開發人員，你遇到過的大多數問題其他人也遇到過；

2 列印調試法：

這是最笨但最有效的辦法，人會說謊、斷點調試可能會說謊，但日誌一定不會說謊；

3 二分排除法：

當你遇到隨機問題、幫助他人解bug或者遇到自己不熟悉的代碼時，通過屏蔽一部分代碼，運行觀察問題仍然存在，如果存在則進一步分析屏蔽一部分代碼，直到定位到有問題的具體位置為止，這種方法能解決工作中的很大一部分疑難雜症；

4 小黃鴨調試法：

當你向某個對象陳述你的思路時，往往會有意想不到的結果，哪怕對方並不是一個生物；斷點調試法：受限於效率不高以及在多線程環境下斷點調試並不靈，有必要時才考慮用這種方法；通常可以使用列印調試法來代替；

5 線上求助：

包括論壇提問、RTX和微信群提問等；不到萬不得已不要用這種辦法，在有限的圈子裡面，你遇到的一個具體技術問題很有可能其他人並沒有遇到過，多數時候問了也是白問，但有時候也可能是一種有效的方法。

很多時候我在想一個合格的開發人員，工作兩年和工作一年有什麼區別；工作多年與工作一兩年又有何區別。得到的結論無非就兩個：

工作越久，應該越靠譜，不然你和剛入這行的小夥伴沒有任何區別；有一套屬於自己的解決問題的方法，遇到任何問題都能夠通過自己的套路去解決。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！