寫程式二十多年累積不少經驗，但是程式的臭蟲未曾少過，雖然一般性與邏輯性的問題較少，但是轉變成系統性的問題，也就是開始規劃新系統時，若有疏漏沒考慮到的情形，就會可能發生問題，小毛病通常容易補漏，但也遇過大問題要系統改寫。
不管是自己寫程式或是帶人進行一些程式開發，在專案末期，常常有人詢問我們軟韌體工程師們一個問題，你的程式是不是最後的版本，還會不會有 bug 啊？他們期待聽到一個 OK 沒問題的答案，但是隔天又怕聽到程式有錯必須改版的情形。以個人經驗，只要是人寫的程式，幾乎都會發生錯誤，那如何觀察程式版本是否穩定？較簡單的方法就是，觀察錯誤發生的頻度，也就是每天除錯次數要遞減，並且好幾天才出現一個錯誤，這樣的軟體才算穩定。
那有沒有數字指標，可以表達軟體沒有錯誤的信心程度？我有一個方法可以利用卜瓦松( Poisson) 機率分佈計算。
這個理論跟等公車的理論是相同的，假設某公車每十分鐘會開出一班，那麼十分鐘內沒有公車出現的機率是多少？
Poisson 機率分佈函數
λ 表示公車在固定時間內出現的平均次數
假設公車固定時間會出現一班，那沒公車出現的機會約 36.79 %
以這樣的方式來對比臭蟲出現率，如果現在每天平均出現一個錯誤，那麼某天沒臭蟲的機率也是 36.79 %，連續三天沒臭蟲的機率約為 5 %，這時候你可以有很高信心程度，認為軟體版本已經穩定，也就是說解決完所有的 bug 再多等三天，沒有任何負面反應才正式對外軟體發行，這樣可以提高他人對你軟體穩定度的信心，當然緊急狀況就沒辦法等了。
至於 5% 是如何算出?我有兩種解法，留給數學高手補充。
授權程式人雜誌 2014一月刊文
軟體設計的除錯階段通常都必須耗費相當長的時間處理，畢竟對消費者來說，花錢買的軟體如果品質良好，便會對該軟體設計公司產生信心。
回覆刪除軟體設計好壞，就像數學在求最佳化一樣，除了local area debug，也要對全面的global area debug.
所以有alpha版和beta版。當測試ok，軟體便誕生。
對於初出茅廬的人員，應該不斷向資深人員請益，有很多寶貴經驗或失敗的經驗，可避免或可學習，對於設計這一條路可節省很多寶貴時間。
謝謝薛老師補充，
回覆刪除設計與除錯都很重要，記得二十年前學生時代，曾寫過一個專題程式，用一週時間設計，卻用三週時間除錯，那是個規劃不周的慘痛經驗，不過還是有人寧可親身經歷，才會學到教訓，哈哈，我就是這種人。^_^