Skip to content
九月 20, 2009 / wychi

軟件調試心得

在windows平台上寫程式也差不多有4年的時間了,
處理過的bug數應該早就破千
不過,很慚愧的, 一直到近期才知道自己在debug還只是個小學生,
能處理的bug只是單純的,能在Visual Studio中重製的簡單bug.

當程式灑出去做公開測試時,才知道這件事沒這麼簡單..
在簡單的邏輯bug之外, 還有很多狀況, 例如,跟系統設定相關的, 跟硬体相關的..
最重要的是當那些錯誤發生時, 你不在現場!!
使用者也不會有耐心告訴你, 他做了什麼事情而產生這個bug
你只能很無助的從使用者的報怨中去推測可能的原因,,這真的很無助啊

所以在真的痛過之後,才明白到 app 是需要做 Error reporting的..
application error reporting這件事, Microsoft早就在做,,
一堆知名的軟体也在好幾年前就提供了這樣的機制
在這裡又在一次證明了, 我們還只是軟件開發的原始人

即然bug是不能避免的, 期待使用者填寫完整的操作注解也是痴心妄想時,
那讓app在發生錯誤的當下有能力可以產生足夠的資訊就變成第一要務啦!!
一個詳細的自己檢測報表,加上一個回送機制,
真的會讓這世界變的友善一點

所以說, 我的理解是
1. 想法辦讓你的app可以產生錯誤報告
2. 讓這些資訊傳回來, (如果這個錯誤以修復, 讓使用者知道如何取得patch)
3. “自動"分析錯誤報告以去除重覆的, 並將錯誤報告做分類,
4. 修復錯誤,並產生patch以供下載
這樣才算是一個完整的循環

所以error handling的範圍已經不單單限於公司中的開發環境 (RDs + QAs)
還需要將廣大的使用群一起涵蓋進來, 如此一來才能妥善的利用群眾的力量來提升軟体的質量

Reference:

Windows Error Reporting: Getting Started

XCrashReport : Exception Handling and Crash Reporting – Part 1

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: