2010年4月8日 星期四

偵錯建議 Debugging Suggestion

Dear all G-Factor's lovely engineers,

大家在開發程式時, 請多使用執行模式 + 檢視 Log, 少用模式設中斷點,

執行模式 + 檢視 Log 的優點如下:
  • 啟動快速, 資源用量少, 效能較佳
  • 執行結果接近真實狀況
  • 訊息量大,且細節多
  • 記錄的Log的程式碼, 可以留下, 且不斷被重覆執行使用, 亦具有註解的功能
  • 多數網頁程式可以立即更新, 檢視結果, 不需重新啟動, 程序重來
模式設中斷點的缺點:
  • 啟動緩慢, 資源用量大, 效能較差
  • 模式的容性較高, 但那不是真實環境的狀況
  • 只能看見當下執行點的資訊
  • 每次, 都是一次重新的來過, 完畢, 什麼都沒留下
  • 發現問題所在, 必需中斷除, 修改程式, 重新測試流程
那何時才使用模式+中斷點? 很簡單, 當以執行過程+Log檔看不出Bug原因時, 就在適當處中斷後仔細看. 最後大家會發現, 這種狀況並不常發生, 執行過程+Log檔檢視, 已可以解決多數問題.

然而, 檢視 Log通常需開啟Log檔, 且要隨時更新檔案, 以檢視最新訊息, 似乎很麻煩.
附件中有一個很不的Log檢視工具, 可以看見立即更新的Log內容, 更可以設定特定訊息的顏色, 例如誤設紅色, 不重要的訊息用淡色, 附圖是其執行畫面, 下載後Rename副檔名為exe.

方法很多, 要交插活用, 不是一個Debug Mode+中斷用到底. 執行模式 + 檢視 Log 的優點很多, 最重要的是每次後都會留下一些東西(Logging Code), 日後自己和別人都受惠, 我認為, 優秀工程師和平庸工程師的差別, 通常就在這一點.

以上建議適用Java專案和.Net專案. 尤其是.Net專案, 因為Microsoft把工具做的太好, 造成過度使用, 而忘記(或根本不知)正確的除觀念.

Eric

沒有留言: