隨想錄（軟體中的bug）

【聲明：著作權，歡迎轉載，請勿用於商業用途。  聯絡信箱：feixiaoxing @163.com】  

 

 

    軟體由於其特殊性，始終和bug緊密地聯絡在一起。沒有bug的軟體是不存在的。為什麼這麼說呢？我們知道，軟體是由很多人完成的，不同的人完成代碼的水平是不一樣的，一旦溝通不暢是很容易引入故障的。另外軟體的需求是時刻在改變的、軟體的修改是每時每刻都在進行的、軟體的外部硬體環境也是在不斷變化的。某些軟體即使現在不存在bug，也可能是因為我們暫時還沒有發現而已，和軟體本身是否沒有bug其實關係不大。

  

    其實，只要你進入軟體開發這個行業，基本上每天都需要和bug打交道，這是不以你的意志為轉移的。問題的關鍵是，對待這些bug故障我們應該這麼做？哪些是必須完成的，哪些是有待改進的，哪些是必須拒絕的。在發現和驗證故障的過程中，有幾條原則是我們需要牢記的，

 

    （1）故障的處理是需要成本的，需要優先處理那些基本業務故障；

    （2）必須使得故障複現，故障必現或者有機率地複現，這樣解決的可能性才會大大提高，否則極有可能沒辦法解決；

    （3）做好故障的描述工作是一件十分重要的事情，恰當、精確的描述可以大大提高問題解決的速度，比如說

        a）當前軟體的版本是什麼；

        b）故障是否必現；

        c）有沒有前提配置；

        d）錯誤號碼是什麼；

        e）故障出現前的最後一個操作是什麼；

        f）故障的基本現象是什麼。

 

    當然，出現了故障總要解決吧。要是故障出現了，真正的原因卻一直查不到，這也是一件什麼惱人的事情。就我個人的經驗來說，一般只要故障可以穩定複現出來，基本上都可以解決的，但是這個中間會有一些處理效率的問題。所以，有一些簡單的準則和方法是需要注意的，

 

    （1）尋找到故障的真實原因，通過日誌和二分法尋找到故障發生的精確地點；

    （2）充分利用故障發生時的日誌資訊、記憶體資料、回溯堆棧和調試資訊等等；

    （3）掌握單步調試的技巧，關注記憶體資料發生的每一點變化，尤其是驗證記憶體越界的時候十分有效；

    （4）解決故障的時候，注意一併處理同類的故障的，比如相似程式碼片段的故障；

    （5）修改故障，驗證代碼，注意不要引入新的故障，其實這是極難的一件事情；

    （6）編寫測試案例，防止類似事件的發生，我自己做得也不好。

 

    當然，話又說回來，正所謂知易行難。很多事情說說很容易，但是真正實施起來的時候往往打了很多的折扣，這也導致我們處理bug的效果常常很不理想。其實也沒有什麼好的方法，關鍵還在於我們自己要及時反省、及時總結吧。不過有一點是肯定的，好的編程習慣可以消除一批類型的故障，比如說記憶體、死結、重複編譯、野指標等等。願這篇文章和大家共勉。