那一夜，你傷害了我……

前兩天，小編用程序員們開發的系統搞事情。

然後，發現了bug。

然後程序員們跟這個bug搏鬥了許久，終於好了。

就在剛才，對，小編又不小心又發現了bug。

……不說了程序員要打死我了。

那麼，遇到bug的時候，都有什麼辦法解決呢？

小編整理了一些隱藏的大神的回答。

@匿名

@YY

1. 注重邏輯性

首先，你要定位 bug，不要做沒有證據的結論。

如果你有猜測，就去證實或者否定它。

比如某次，同事代碼返回的數據有問題，認為是緩存用的 Redis 有問題，返回了錯誤的數據。

然而沒人去對此猜測進行求證……

我去確認了一下，Redis 收到了請求，並且響應正常。

真相就是，代碼里有個 } 的位置放錯了，因為它剛好在一屏之後的位置，所以沒有人發現……

2. 基本的方法論

比如二分法。

比如最小化測試用例。

如果你要提問，不管是向搜索引擎還是向人，你都需要提出正確的問題。

3. 知識面

你寫 Web 後端的話，普通的 HTTP 得懂，瀏覽器的開發者工具得會用。

簡單的 JavaScript 也有會點兒。

簡單地說就是，你要精於你自己主攻的部分，然後要熟悉你的上下游。

再比如如果你使用 CPython 的話，你要準備一份 CPython 的源碼，並且要能夠流暢地閱讀 C 代碼。

4. 工具

工欲善其事，必先利其器。

一大堆調試用的工具，你至少得知道它們能幹什麼，需要的時候能用。

比如 strace、lsof、gdb、git bisect，還有 sysdig、systemtap、perf 等。

當然還有一堆不是專門為調試而設計的通用工具，比如 the silver searcher 或者 ripgrep。

一個快速的全文搜索工具能幫你在最短時間內找到相關的代碼或者日誌。

你不必成為正則表達式大師，但是簡單的一定要會。不然面對上千個匹配結果你要怎麼辦呢？

@jim jin

先試試以下步驟：

1. 換個環境試試

2. 換個用戶試試

3. 換個操作方法試試

4. 換一下數據試試

5. 換個瀏覽器試試

6. 換個版本試試

7. 換個人操作試試

下面列出一些常見的疑難BUG類型以及每種BUG的診斷方法：

1. 輸出結果與預期不符

這種BUG一般都是由於代碼邏輯錯誤造成的。

如果能在開發環境重現，最好解決方法就是單步調試，設定每一步代碼的預期結果。

然後跟蹤判斷實際結果是否與預期結果一致。

如果在開發環境無法重現，無法單步調試的，可以採用添加輸出日誌的方式判斷哪一步的問題。

2. 系統異常報錯

這種情況下需要提取日誌，找出錯誤堆棧信息。

這時候最重要的事情是要把堆棧信息看懂、看完整。

往往堆棧信息是一個套一個輸出的。

比如Java裡面表象上看是一個NullPointer Exception，但是如果你看到底，就會告訴你到底是什麼錯誤引發了這個NullPointer。

3. 系統Crash

這個問題常見的原因是負載過高、並發過高、或者配置錯誤。

最常見的就是內存溢出。

這時候要首先排除配置錯誤的原因，主要靠查看Crash Log來分析原因。

如果Crash Log沒有有用的信息，就得排查硬體、內存、網路等方面的設置，看是否有配置錯誤的地方。

再找不到就在測試環境用開發模式進行壓測和調試。

4. 系統響應緩慢

這種問題一般是存在資源競爭或者系統資源不足的情況。

最後，如果某個地方出現BUG實在找不出什麼原因，那就上我們的絕招——「小黃鴨調試方法」吧。

• 去買一隻小黃鴨，就下面這樣的，注意個頭不要太大。

• 把小黃鴨放到電腦屏幕上方，就下面這樣的，最好面對著你。

• 打開你出問題的那段代碼，面對小黃鴨。用手指著代碼。一行一行的給它解釋一下這行代碼是幹什麼的，為什麼這麼寫。
• 現在你知道問題所在了嗎？

各位程序員，小編只能幫你們到這啦！

祝大家天天開心，永遠沒bug~

https://u.wechat.com/MMFd7gieWyD03EisPz_YG3I (二維碼自動識別)

推薦閱讀：