經過4天的奮鬥, 總算把解封包演算法的Bug解決, 分享一下長久一來我的解Bug經驗, 雖然我還稱不上什麼武林高手, 但是這些經驗幫我渡過不少難關, 應該頗具有參考價值
- 當Bug出現的時候, 先使用Bug資料庫, 或是Issue Tracking軟體新增一個Bug.
我記得剛開始寫程式的那幾年, 遇到Bug, 第一件事就是先跳進去Source code 看問題到底出現在那裡? 但是往往Bug還沒解完, 其它事接踵而來, 開會,等等的中斷, 當思緒已經快想出問題的解法, 確因為"中斷"造成下次再接下去解Bug的時候又要重來. 所以先在Bug資料庫新增一個Bug, 看似很簡單, 但是這個習慣確是我工作兩三年後才養成的習慣. - 勤寫Bug Comment
將心中對於Bug會發生的所有可能性記下來, 當思緒打結的時候, 將目前的進度與結果做個記錄. 這些記錄寫在資料庫中所建立的Bug是最好的. 以我解Bug的經驗, 每當遇到很棘手的Bug, 心中總是千頭萬緒, 不知從何下手, 在這思考的過程中, 沒有將思考的結果寫下來, 最後很容易陷入"思考的迷宮" , 思緒一直在繞圈圈, 走也走不出來, 但是有做記錄, 雖然會花一點時間, 但是確可以review自己的思路, 很快就可以找到出路. - 善用Log message
例如 Java 的log4j , Object-C的NSLog. 如果是寫底層的device driver也是有對應的log utility. 使用Log也要有一些技巧性, 我的經驗是, 先將source code好好看過一次, 然後在可疑處下Log, 然後從console看Log是否按照自己所設計的邏輯顯示出來. 如果是Fat client程式 而且沒有具備通信功能, IDE的source level debugger就夠用了, 但是目前的程式幾乎都具備有通訊功能, source level dugger在解決realtime的訊息就略顯不足. - 使用第三方工具驗證
當解Bug陷入膠著, 通常我會找其它功能正常的工具來驗證, 這種情況在寫DLL, Library或是framework常遇到, 例如我在解通訊程式的封包問題, 我可以先找已經可以正常工作的第三方軟體, 觀察正常的封包到底是長什麼樣子, 不過 這有點像是在做逆向工程, 一開始開發的產品是獨一無二的產品,可能就不適用了. - 學習使用驗證工具或是儀器
如果是寫純軟體, 通常SDK會附有許多工具, 例如記憶體的使用檢測, 如果是寫device driver, 我以USB device為例, USB有一種儀器叫USB analyser, 可以很清楚看到資料的傳遞流程. 在寫TCP/IP網路通訊程式, 可以使用tcpdump 所以解Bug時, 如果能善用這些工具, 可以讓你解Bug的時間大幅減少. 不過以我的經驗, 都是所有的方法都用盡了到最後不得已才使用這些工具. - 勤加閱讀
閱讀,等於是在幫自己補充解決問題的能量, 以往為了了解問題的核心所在, 得先將相關技術文件狠狠的K一遍, 所以解決問題絕不是靠天外神來一筆. 多方閱讀非資訊以外的文件對於思考也有很大的幫助 - 善用網路社群/Google搜尋引擎
剛開始寫程式時, 網路並不是很發達, 大概只有News群組可以找到一群同好討論, 或是使用MSDN尋找解答, 但是自從有了Google, 只要會利用關鍵字,很快就可以看到相關的問題討論, 並獲得解答. 不過真的要 懂得用問題核心的"關鍵字", 我看過許多Engineer不會用google找答案, 真的是很可惜.
留言