毫無疑問，程序員是善于思考問題的一族。一個程序的編寫都是通過：思考、設計、編寫、調試、測試以及運行這些基本的階段。但大部分程序員都有一個問題就是不太愿意測試自己的代碼。他們草草的調式完成以后就認為工作結束，測試那是測試人員的工作。
按照理論上，如果代碼存在問題，那么測試人員和最終的用戶肯定可以發現這些
BUG
，而等待哪個時候再返回來查找問題到底錯在什么地方確實代價不小，其代價有：
1．?
影響了程序員自己的聲譽
2．?
影響了產品的質量
3．?
影響了客戶的信任度
4．?
這個時候再
DEBUG
難度增大了許多。
大的不說，就說多自己聲譽的影響吧。如果你的程序總會有這樣那樣的
BUG
，你得到收益會減少，即使你寫了很多代碼。
其實最后一點也很重要；在我們面對一塊代碼的時候，什么方法都好辦，但如果將這塊代碼防到龐大的系統中之后，簡單的問題也難以被立即找出來。為了自己考慮，節省自己
DEBUG
的時候，我們應該讓我們的程序盡量沒有
BUG
。
那么怎么樣才能保證自己的代碼沒有
BUG
來？?
?
程序員必須克服一些自身的致命缺點才能夠從根本上解決這個問題。那么這個問題是什么？前面我們已經提到，程序員對自己的代碼都非常寬容，認為那是正確的沒有問題。實際上這種想法比較正常，程序是通過程序員思考和設計之后才寫出來，程序員不會將自己認為不正確的東西寫到代碼里，而到這個時候都一直假設程序是正確的；但人非圣賢，怎么可能不犯錯誤來。實際上程序員在對待其他程序員時候的態度就很好，帶著一種挑剔和學習的態度；但一旦對待自己的代碼就很難這么做；這就是最致命的。程序員也必須對自己的代碼帶著挑剔和學習的態度；這個基礎是假設自己的代碼是錯誤的，然后需要做的是怎么樣證明自己的代碼是正確的。程序員自身可以在程序生成的每個階段做這些工作：仔細的設計（這個時候畫點時間是值得的，必須保證我們對自己的程序有清晰的輪廓后才能開始動手寫）、編寫代碼時、單元測試（單元測試的重要性就不在贅婿了）、功能測試。
仔細的設計：這個的仔細是說在程序員編寫代碼之前，其必須對代碼的整個結構以及邏輯結構有明確的清晰的了解，只有這個時候才可以去寫代碼。這里沒有談到文檔，但我說到了一定要清晰的思路，但清晰的思路不是每個人都可以在腦袋中直接形成的，很多人都是普通人，沒有辦法在腦袋瓜中把所有問題都想清楚，那么就記下來，特別對于復雜的邏輯。
編寫代碼：對于沒有把握的代碼，例如：新設計的算法，最好保證其正確性。可以單獨將這部分測試，這可以讓代碼模塊化的同時又保證了代碼的正確性。一句話：少量的代碼保證質量還是比較簡單的。
單元測試：單元測試的重要性不在贅敘了，現在也有許多工具可以幫助程序員并減少工作量。
功能測試：程序員保證自己代碼質量的最后一關；為了做這樣的工作我們可能必須寫一些代碼來測試，甚至是測試工作。使用大量的
CASE
來測試，以及錯誤的
CASE
。這里和測試人員的測試不同之處在于：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
?
如果你通過了以上的步驟都找不出你程序中有任何問題的話，那么我想你的程序應該足夠健壯了。其實還有一點必須說明的就是：代碼
REVIEW
。
前面說道了程序員對待別人代碼的態度是挑剔和學習的態度，所以讓其他程序員來
REVIEW
你的代碼也是檢查程序有沒有邏輯錯誤的很好的辦法。團隊中應該交叉
REVIEW
代碼，這是實踐的經驗。
作為一個好的程序員必須有以上的習慣，以及對待自己代碼象孩子一樣，我們要愛惜我們的代碼，同時也要讓代碼走正確的路。
(有感于程序員的八榮八恥?而發)