DEBUG備忘錄

最近，我和自己的團隊開發了不少程式，隨之而來，就是出現了很多BUG；Debug的工作，老實說，我覺得其實很疼苦和無奈；有時候，就算用了多時間出來，也毫無進展。所以，我打算整理一些一下相關資料和經驗，讓日後的DEBUG工作更有效率。

希望這次的分享，也能幫助大家的DEBUG工作。

內容大綱

• Debug的流程
• 修復問題的方法
• 有助Debug的清單

備註：這裡提及的Debug主要針對一般和Runtime錯誤；至於編譯問題，效能問題，Rendering問題，或者硬體程式，那些需要更多資訊和研究；本文沒有覆蓋那些比較深入的部分。

一般Debug的流程

先簡單說說，一般處理一個Bug的流程，大概流程如下：

重現問題 > 檢查日誌 > 修復問題 > 複檢 > 跟進處理

重現問題

就是把匯報的問題，自己重現一次；因為，如果這一步做不了的話，就不能確定問題是否能成功修復。

檢查日誌

就是看看日誌（log）內有沒有報錯或者異常（Exception），有一些簡單的問題，看了日誌後，就能快速修復了。

修復問題

就是把問題(Bug)處理，下文會詳細討論更多細節；

複檢

複檢除了檢查當前問題是否解決了，還要看看受影響的部分是否出現問題，可以的話，當然是把核心功能複檢一次；

跟進處理

確定修復後，就是一些跟進工作，包括反饋，QA和進行修復更新；
不過怎樣，最基本的事情，就是把結果反饋給提出問題的人，就算解決不了，也需要交代一下。
而其他部分的工作例如QA和更新，可能是其他人處理的；又或者會導入CI/CD系統，這裡不作深入的討論了。

修復問題的方法

這一段會多點討論有什麼方法去修復問題，在討論方法之前，會先說說有那些問題會產生BUGS;

在繼續看之前，請大家用幾分鐘的時間，
想想過去遇到的BUG，是那些原因導致。

BUG常見的原因

想好了沒？那麼到我列舉我想到的原因，主要有 3 點：

1. 數據出錯 （Incorrect Data）
   • 數據的錯誤，會就令後續的輸出和邏輯產生BUG。
   • 錯誤數據，可以是輸入時出現，或者過程中出錯；
     例如：Type Cast問題, double變了float。
   • 對數據單位不了解；
     例如：time 值 轉換成 Date；有些SDK用“秒“，有些會用“毫秒“來轉換。
2. 邏輯出錯 （Incorrect Logic)
   • 邏輯的錯誤，就是執行的順序寫得不正確而導致的BUG。
   • 常見的情況，就是沒有處理一些東西；
     例如：沒有釋放內存，或者沒有按照需求進行。
   • 假如是多線程環境，還有同步性（Concurrency） 和 競爭條件（Race Condition）等問題。
3. 錯誤假設 （Incorrect Assumption）
   • 錯誤假設就是編程者對代碼一知半解。
   • 大家很常常會複製一些範例代碼作為己用；但是，有些代碼不一定適合任何情況，必須需要進行一些設定或改動才能運行正確。
   • 沒有認真看文檔，錯誤地使用API導致問題出現。

解決方法

方法很簡單，就是：

找出BUG的原因，然後對症下藥！

下面會分享一下 “找BUG” 和 “對症下藥” 的方法 ^_^

找出BUG原因

以下是一些找出BUG原因的方法：

• 查考日誌
  這個方法最簡單，不過需要好好的寫日誌和有好的方法過濾日誌內容。
• 使用Debugger
  使用Debugger的斷點(Break Point)，可以知道代碼是否能進入你預期的邏輯中，也可以看到當時的數據是否正確。
• 編寫和使用單元測試 (Unit Test)
  單元測試有效找出不同輸入對應的輸出是正確
• 過去項目經驗
  過去在項目出現過的問題，很多時候會在新項目再次出現。
  所以，修復問題後，最好把解決方法寫一下，或者記在腦裡（次好）。
• 批判性思维 (Critical Thinking)
  很多情況，日誌和Debug工具都能有效發現問題；但是也有不少情況，日誌和Debugger都找不了；那時候，就需要思考問題的根源在那裡，要多想不同的可能性並且加以驗證。

對症下藥

其實能找出BUG的原因，很多時候就能很快解決問題，例如修復數據錯誤，補充遺漏的邏輯等；

如果不能簡單修復的問題，可以考慮這些做法：

• 製作單元測試，把問題的地方隔離，這樣可以加快測試和驗證的流程。
• 暫時屏蔽某些邏輯，減少出現問題的變數。
• 加深了解相關代碼和相關代碼使用的SDK。
• 到互聯網上求救：可以去Stackoverflow，開發群組，或者連續給SDK/API的開發者。
• 砍掉重練？ 這個其實是一個‘辣‘的方法，如非必要，應該不要做。
  但是如果時間許可，而能根治問題，其實值得做；
  但如果是已經運作的系統，就需要從長計議了。

有助Debug的清單

最後，整理一下對Debug有幫助的東西：

1. 測試環境 (包括測試設備，數據，平台)
2. 單元測試框架 (例如：Junit, cppunit, mocha)
3. Debugger
4. 日誌API (例如：log4j, log4net, 或系統本身的提供的)
5. 崩潰報告工具 (例如：Firebase Crashlytics)
6. Bug追蹤系統 (例如：Asana, Bugzilla, ..)
7. 自製工具 (例如：把一些數據顯示，或重置用戶狀態)
8. 自動化測試 （避免修復一個Bug，產生二個Bug的問題）
9. 更快的電腦，或者編譯很快
10. Source Control (必要時，可以查看舊版本比較)
11. 乾淨的代碼 (Clean Code)
12. 開發論壇/群組
13. 官方文檔

總結

對於編程的人來說，Debug是無可避免的工作而且很花時間，所以對於我們來說，
很值得花點時間去改善Debug的方法，讓Debug的時間減少；
當然更好的做法，就減少Bug出現的機會。

如想和我討論更多關於Debug的事情，或者有好的建議分享，可以在這裡留言或到Facebook找我 ^_^ .