一個合格的程序員，應該重視Bug，並在實際項目開發過程中，有效地規避這些Bug，當然也要分情況。有些Bug，在有些情況下建議不要做太嚴格的規避，否則的話，可能會對整個項目的開發進程產生嚴重的阻礙。個人的開發實踐證明，很多項目不是設計死的，而是被測試人員測死的，如果您也有同樣的感觸，那麼，我相信下面的一些觀念，會對您的代碼生涯產生一定的影響……
什麼是Bug？通俗地講就是程序項目開發過程中出現的一些影響項目正常運轉的那些部分。比如：錯誤的邏輯關係處理，不正常的參數獲取方式，數據庫查詢不合理導致您變成一個職業的數據庫殺手，以及用戶體驗不太好等等。這些Bug，有主次輕重之分，在實際項目開發過程中，有些必須規避，有些可以在前期適當放寬要求。當然也要看具體的項目用途，本文中主要以PHP項目開發來舉例。
一、界面類
如果是Web站點，作爲商業用途，那麼界面不達標，即不能達到大器具有足夠的商業氣息，不能在一定程度上體現這個站點的商業特點的界面，公司的項目負責人根本就不應該審 批通過。不要認爲界面還可以再加工再改版，一個好的界面，應該在用戶腦海中停留足夠的時間，而不應該三兩個月就動一次大手術。
界面是Web站點吸引眼球的第一要求，雖然我們通常說Web站點內容爲王，但是一個好的界面能使用戶留下好的印象，爲什麼我們不做的更好呢？對於界面，我的理念一直是：“我們不渴求完美，但是我們要儘量追求完美”。 同時要兼顧項目進度，項目負責人要把項目用途及特點充分地講解給設計師，並提供足夠的資料供其使用和參考，之後不加干涉，讓其用心發揮。一般有經驗的設計師，只要能充分地理解這個項目，設計出來的界面都不會太差。
二、功能類
功能是一個項目的核心。因此，功能邏輯我們一般來講是不允許有便差的。尤其是核心邏輯，比如設計到資金運轉的，務必不能出現差錯。還要建立足夠的備份機制。程序設計上我們建議，獨立的功能務必合理封裝，以便於將來維護。同時，寫清楚註釋，否則，當封裝的內容多了，三兩天之後，可能你自己都看不懂自己寫的是什麼。這已經被無數次地驗證。因此對於複雜的功能，我們必須添加註釋。不加註釋嚴重來講不能算Bug，但實際上它在項目維護的時候，比有些Bug更要你的命。
關於功能類的Bug，我們還要特別注意，不要使用未經安全驗證的插件。比如，封裝不好的數據庫操作類，後臺使用的存在可攻擊漏洞的多功能編輯器，以及封裝不好的或完全未封裝的上傳類等等。有些插件本身有Bug，如果你用了，就等於你寫的程序一樣有Bug，而且還很要命，尤其是用了一些開源的插件，如果它的Bug未修復，你的程序可能在一夜之間全部變成廢品。因此，我們要慎用開源插件。
三、數據處理類
數據處理類最常見的是數據有效性檢測不合理，這個問題在初學編程的程序員身上最爲突出。比如POST或GET方式接收的參數，不經過濾就接收使用。這有可能對數據庫造成致命傷害，進而影響到服務器的安全。說白了就是出現SQL注入的漏洞。如果您是初學者，不清楚SQL注入，建議您趕緊搜索點資料研究一下。否則您寫的代碼可能一直都站在懸崖邊上，隨時有粉身碎骨的可能。第二種情況是雖然過濾了，但是不判斷，程序員往往在寫 程序的時候，都會自己簡單測試。但是這種測試是站在一個正常思維的角度去測試的。
比如，你要發表一篇文章，你肯定會填寫一些內容然後再點提交，但是我們就 是有用戶，他不填內容就點擊提交。如果你不判斷提交的內容是否爲空就直接向數據庫中插入一行記錄，那不僅僅是浪費數據庫資源，更重要的是讀出來顯示給用戶 看的時候，你可能還納悶，爲什麼不顯示內容，還以爲自己的顯示處理代碼有Bug，因此，很多程序是相互依賴的，如果你能在重要的地方處理好，就可以在另外一個地方少些判斷少些處理。反而可以提高程序性能。雖然某些性能看起來微乎其微，但是我們順手牽羊，提高一點總比沒有好。
四、提示信息
關於提示，我們這裏主要說兩點：
其一、很多程序員喜歡複製粘貼自己前面寫的提示信息的代碼（因爲提示信息一般是封裝好的一個方法），特別是類似的功能提示。 這樣一來，經常造成一些不合理的提示出現。比如你在在刪除失敗的時候，複製了一份刪除成功的提示，那麼巧了，如果你刪除的時候，傳的參數處理存在Bug，可能你每次點刪除按扭的時候，系統都提示你刪除成功，其實這時是不成功的。有時候你寫代碼可能就是把腦代給寫昏了，說不定你反覆點來點去，一直認爲是程序有數據處理的Bug，而實際上僅僅是一個提示錯誤而已。白白浪費你太多時間。
其二、建議Web程序多留些旁註，簡單明瞭地告訴用戶當前位置的操作方法。不加旁註，不是一種Bug， 但是它可以有效地規避由於用戶操作不合理而給公司或者你個人帶來極大的維護成本。如果你在寫程序的時候，在每一個用戶的關鍵操作點，都有旁註，相信你平時的麻煩事應該很少。喜歡加旁註的人，曾經一定有類似的傷心史。所以他長教訓了：“我讓你還不斷地問！我哪有那麼多精力解答你！”
五、性能類
談到性能類，建議不同的項目區別對待，小項目有小項目的做法，大項目有大項目的做法，不同的項目在不同的階段，針對性能設計也要區別對待，不建議一視同仁。如果是個小項目，日訪問量不足百十來個IP，你也去做什麼靜態化處理，啓用海量數據處理方案，搞複雜的服務器組織結構，那真是：“自作孽，不可活”呀。我曾經經手過一個Web站，本來訪問量每天幾百個不得了，有時候不足幾十個，結果想了一大堆方案，預想着網站馬上會有一堆流量。結果，流量沒上來，項目搞了半年還說不合理，承受不了大的訪問量，天天又糾結一些幾乎不會出現既便是出現了也不會對站點造成什麼影響的Bug。最後商機慢慢也沒了，燒了幾百萬，換了幾張空頁面。股東嚇的紛紛撤股。真可謂，有錢沒地方使。
另外補充一點，給項目負責人看：項目的不同時期要把握好項目的進度，對測試人員也要有不同的要求，不要爲了一味的排除所謂的Bug，而把項目做死了。再補充一點，給開發人員看，閒的時候，多找些程序優化的知識看看，多總結一些常見的Bug解決方法。在實際的項目開發過程中，自己知道的Bug處理方法儘量全部用上，至少在個人知識層面上不要出現Bug，這不僅是一種工作的態度，最重要的是對整個項目負責。經驗多了，Bug會越來越少，重點就可以集中在邏輯功能的處理上，纔可以使你的代碼質量越來越高。
最後一條，老生常談：我們做程序，要把用戶當傻瓜，雖然不中聽，但是確實是一條人間正道！