【51CTO獨家特稿】一個合格的程式設計師，應該重視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會越來越少，重點就可以集中 在邏輯功能的處理上，才可以使你的程式碼質量越來越高。

最後一條，老生常談：我們做程式，要把使用者當傻瓜，雖然不中聽，但是確實是一條人間正道！