評“程式員怎麼樣才能保證自己的程式沒有BUG”

評“程式員怎麼樣才能保證自己的程式沒有BUG”

代碼複核(Review)是為了找錯誤嗎？看代碼能看到邏輯錯誤嗎？
不，跑測試程式都不能找到錯誤，看代碼怎麼可能看出來？
複核代碼的目的有：
* 檢查代碼是否規範，如命名規範，注釋
* 保證一段代碼至少有兩人共同熟悉，可以由任一人來更改。
* 檢查設計思想是否如實實現，代碼如何表達設計
* 審察未文檔化的細節設計，即由代碼直接表達的設計，由代碼人口述設計並對照代碼
* 檢查是否暴露出原設計的缺陷，需要重新設計？

程式員是否認為自己的程式有錯誤？
自信沒有錯誤和懷疑代碼還有錯誤，哪個是正確的心態？
我認為程式員永遠都不會有100%的自信。
即使程式已經發布，被使用者接受很長時間，只有好評沒有抱怨，依舊不能確認有沒有錯誤。
只能假定錯誤是永恒的，它們一直在那裡，只是不到條件爆發。
一個程式員能做的就是，排除所有膚淺的錯誤，加大隱藏錯誤出現的幾率並找到它們，
採用一些容錯性代碼減小可能的錯誤，減少程式發布後爆發的機率。

測試的目的是為了發現錯誤，
但是單元測試，功能測試的覆蓋度能有多高？
沒有100%覆蓋的測試。就是說，總是有一些狀態是測試不到的。
代碼人員認為不可避免地存在錯誤，需要測試，測試人員認為測試覆蓋度不可能100%，還是要代碼小心。
這是一個頭痛的問題，結果是沒有完美的程式。

單元測試是白箱測試，可以根據代碼實現將注意力放到最關鍵的部位。
但仍然不是100%覆蓋的。
單元測試一般針對的是邊界資料，不要求覆蓋度，而更要求有效性。
其目的更主要的是保證代碼更改不會破壞原有的正確性，是提供保障而不是尋找故障。

保證沒有錯誤的唯一方法是不寫代碼，減少錯誤的最好方法是少寫代碼。
簡單的設計和實現是減少錯誤的最佳方法。簡單的代碼錯誤必定少。
畫蛇添足式的功能則是最大的錯誤發源地

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/jq0123/archive/2006/07/07/890147.aspx