程式設計師如何快速高效的改 bug?改bug都有哪些技巧?

NO IMAGE

1. 這個BUG偶爾才能出現,或者只在特定的環境裡面出現。
2. 不知道BUG是什麼問題造成。
3. 不知道BUG該怎麼下手解決。

如果遇到這樣的問題可能好幾天都不得其解,搞得人焦頭爛額,這時候就不要左改一下,右改一下了,而是要冷靜下來,先理理頭緒。

先根據情況試一下下面的步驟:
1. 換個環境試試
2. 換個使用者試試
3. 換個操作方式試試
4. 換一下資料試試
5. 換個瀏覽器試試
6. 換個版本試試

根據上的情況搞清楚下面這幾個問題:
1. 這個BUG什麼情況下出現?什麼情況下不出現?兩種情況的區別在哪裡?
2. 這個BUG之前沒有,現在出現了,中間都動了什麼?
3. 這個BUG生產環境出現測試環境不出現,兩個環境區別是什麼?
4. 同樣的功能,這樣操作沒有BUG,那樣有BUG,兩個操作的區別是什麼?

這些問題搞清楚了,先嚐試採用程式碼回退、配置調整、環境替換等方式驗證BUG是否會消失,然後再找其中的原因。

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

1. 輸出結果與預期不符,這種BUG一般都是由於程式碼邏輯錯誤造成的,如果能在開發環境重現,最好解決方法就是單步除錯,設定每一步程式碼的預期結果,然後跟蹤判斷實際結果是否與預期結果一致,不一致的分析原因,如果在開發環境無法重現,無法單步除錯的,可以採用新增輸出日誌的方式判斷哪一步的問題。
2. 系統異常報錯,這種情況下需要提取日誌,找出錯誤堆疊資訊,這時候最重要的事情是要把堆疊資訊看懂、看完整。這是很多經驗不足的程式設計師常見的問題,就知道報錯了,報的什麼錯,這個錯代表什麼一概不知。而且往往堆疊資訊是一個套一個輸出的,比如Java裡面表象上看是一個NullPointer Exception,但是如果你看到底,就會告訴你到底是什麼錯誤引發了這個NullPointer。
3. 系統Crash,這個問題常見的原因是負載過高、併發過高、或者配置錯誤。最常見的就是記憶體溢位。這時候要首先排除配置錯誤的原因,主要靠檢視Crash Log來分析原因,如果Crash Log沒有有用的資訊,就得排查硬體、記憶體、網路等方面的設定,看是否有配置錯誤的地方。再找不到就在測試環境用開發模式進行壓測和除錯。
4. 系統響應緩慢,這種問題一般是存在資源競爭或者系統資源不足的情況,先檢查伺服器內容、CPU、網路情況,如果伺服器壓力過大,排查應用系統負載情況是否異常,如果這些資料都正常,就需要排查程式碼中的效能瓶頸,可以採用profile工具或者直接輸出時間戳的方式檢視哪個操作佔用時間最長。特別需要留意依賴第三方介面的情況,比如同步的方式傳送郵件、傳送簡訊、寫檔案等。

最後,如果你依然是毫無頭緒,機謀用盡,那就得上我們的絕招“小黃鴨除錯方法(Rubber Duck Debugging)”了。