一個合格的程序員，應(yīng)該重視Bug，并在實際項目開發(fā)過程中，有效地規(guī)避這些Bug，當(dāng)然也要分情況。有些Bug，在有些情況下建議不要做太嚴(yán)格的規(guī)避，否則的話，可能會對整個項目的開發(fā)進程產(chǎn)生嚴(yán)重的阻礙。個人的開發(fā)實踐證明，很多項目不是設(shè)計死的，而是被測試人員測死的，如果您也有同樣的感觸，那么，我相信下面的一些觀念，會對您的代碼生涯產(chǎn)生一定的影響……

　　什么是Bug？通俗地講就是程序項目開發(fā)過程中出現(xiàn)的一些影響項目正常運轉(zhuǎn)的那些部分。比如：錯誤的邏輯關(guān)系處理，不正常的參數(shù)獲取方式，數(shù)據(jù)庫查詢不合理導(dǎo)致您變成一個職業(yè)的數(shù)據(jù)庫殺手，以及用戶體驗不太好等等。這些Bug，有主次輕重之分，在實際項目開發(fā)過程中，有些必須規(guī)避，有些可以在前期適當(dāng)放寬要求。當(dāng)然也要看具體的項目用途，本文中主要以php項目開發(fā)來舉例。

　　一、界面類

　　如果是Web站點，作為商業(yè)用途，那么界面不達標(biāo)，即不能達到大器具有足夠的商業(yè)氣息，不能在一定程度上體現(xiàn)這個站點的商業(yè)特點的界面，公司的項目負責(zé)人根本就不應(yīng)該審 批通過。不要認為界面還可以再加工再改版，一個好的界面，應(yīng)該在用戶腦海中停留足夠的時間，而不應(yīng)該三兩個月就動一次大手術(shù)。

　　界面是Web站點吸引眼球的第一要求，雖然我們通常說Web站點內(nèi)容為王，但是一個好的界面能使用戶留下好的印象，為什么我們不做的更好呢？對于界面，我的理念一直是：“我們不渴求完美，但是我們要盡量追求完美”。 同時要兼顧項目進度，項目負責(zé)人要把項目用途及特點充分地講解給設(shè)計師，并提供足夠的資料供其使用和參考，之后不加干涉，讓其用心發(fā)揮。一般有經(jīng)驗的設(shè)計師，只要能充分地理解這個項目，設(shè)計出來的界面都不會太差。

　　二、功能類

　　功能是一個項目的核心。因此，功能邏輯我們一般來講是不允許有便差的。尤其是核心邏輯，比如設(shè)計到資金運轉(zhuǎn)的，務(wù)必不能出現(xiàn)差錯。還要建立足夠的備份機制。程序設(shè)計上我們建議，獨立的功能務(wù)必合理封裝，以便于將來維護。同時，寫清楚注釋，否則，當(dāng)封裝的內(nèi)容多了，三兩天之后，可能你自己都看不懂自己寫的是什么。這已經(jīng)被無數(shù)次地驗證。因此對于復(fù)雜的功能，我們必須添加注釋。不加注釋嚴(yán)重來講不能算Bug，但實際上它在項目維護的時候，比有些Bug更要你的命。

　　關(guān)于功能類的Bug，我們還要特別注意，不要使用未經(jīng)安全驗證的插件。比如，封裝不好的數(shù)據(jù)庫操作類，后臺使用的存在可攻擊漏洞的多功能編輯器，以及封裝不好的或完全未封裝的上傳類等等。有些插件本身有Bug，如果你用了，就等于你寫的程序一樣有Bug，而且還很要命，尤其是用了一些開源的插件，如果它的Bug未修復(fù)，你的程序可能在一夜之間全部變成廢品。因此，我們要慎用開源插件。

　　三、數(shù)據(jù)處理類

　　數(shù)據(jù)處理類最常見的是數(shù)據(jù)有效性檢測不合理，這個問題在初學(xué)編程的程序員身上最為突出。比如POST或GET方式接收的參數(shù)，不經(jīng)過濾就接收使用。這有可能對數(shù)據(jù)庫造成致命傷害，進而影響到服務(wù)器的安全。說白了就是出現(xiàn)SQL注入的漏洞。如果您是初學(xué)者，不清楚SQL注入，建議您趕緊搜索點資料研究一下。否則您寫的代碼可能一直都站在懸崖邊上，隨時有粉身碎骨的可能。第二種情況是雖然過濾了，但是不判斷，程序員往往在寫 程序的時候，都會自己簡單測試。但是這種測試是站在一個正常思維的角度去測試的。

　　比如，你要發(fā)表一篇文章，你肯定會填寫一些內(nèi)容然后再點提交，但是我們就 是有用戶，他不填內(nèi)容就點擊提交。如果你不判斷提交的內(nèi)容是否為空就直接向數(shù)據(jù)庫中插入一行記錄，那不僅僅是浪費數(shù)據(jù)庫資源，更重要的是讀出來顯示給用戶 看的時候，你可能還納悶，為什么不顯示內(nèi)容，還以為自己的顯示處理代碼有Bug，因此，很多程序是相互依賴的，如果你能在重要的地方處理好，就可以在另外一個地方少些判斷少些處理。反而可以提高程序性能。雖然某些性能看起來微乎其微，但是我們順手牽羊，提高一點總比沒有好。

　　四、提示信息

　　關(guān)于提示，我們這里主要說兩點：

　　其一、很多程序員喜歡復(fù)制粘貼自己前面寫的提示信息的代碼（因為提示信息一般是封裝好的一個方法），特別是類似的功能提示。 這樣一來，經(jīng)常造成一些不合理的提示出現(xiàn)。比如你在在刪除失敗的時候，復(fù)制了一份刪除成功的提示，那么巧了，如果你刪除的時候，傳的參數(shù)處理存在Bug，可能你每次點刪除按扭的時候，系統(tǒng)都提示你刪除成功，其實這時是不成功的。有時候你寫代碼可能就是把腦代給寫昏了，說不定你反復(fù)點來點去，一直認為是程序有數(shù)據(jù)處理的Bug，而實際上僅僅是一個提示錯誤而已。白白浪費你太多時間。

　　其二、建議Web程序多留些旁注，簡單明了地告訴用戶當(dāng)前位置的操作方法。不加旁注，不是一種Bug， 但是它可以有效地規(guī)避由于用戶操作不合理而給公司或者你個人帶來極大的維護成本。如果你在寫程序的時候，在每一個用戶的關(guān)鍵操作點，都有旁注，相信你平時的麻煩事應(yīng)該很少。喜歡加旁注的人，曾經(jīng)一定有類似的傷心史。所以他長教訓(xùn)了：“我讓你還不斷地問！我哪有那么多精力解答你！”

　　五、性能類

　　談到性能類，建議不同的項目區(qū)別對待，小項目有小項目的做法，大項目有大項目的做法，不同的項目在不同的階段，針對性能設(shè)計也要區(qū)別對待，不建議一視同仁。如果是個小項目，日訪問量不足百十來個IP，你也去做什么靜態(tài)化處理，啟用海量數(shù)據(jù)處理方案，搞復(fù)雜的服務(wù)器組織結(jié)構(gòu)，那真是：“自作孽，不可活”呀。我曾經(jīng)經(jīng)手過一個Web站，本來訪問量每天幾百個不得了，有時候不足幾十個，結(jié)果想了一大堆方案，預(yù)想著網(wǎng)站馬上會有一堆流量。結(jié)果，流量沒上來，項目搞了半年還說不合理，承受不了大的訪問量，天天又糾結(jié)一些幾乎不會出現(xiàn)既便是出現(xiàn)了也不會對站點造成什么影響的Bug。最后商機慢慢也沒了，燒了幾百萬，換了幾張空頁面。股東嚇的紛紛撤股。真可謂，有錢沒地方使。

　　另外補充一點，給項目負責(zé)人看：項目的不同時期要把握好項目的進度，對測試人員也要有不同的要求，不要為了一味的排除所謂的Bug，而把項目做死了。再補充一點，給開發(fā)人員看，閑的時候，多找些程序優(yōu)化的知識看看，多總結(jié)一些常見的Bug解決方法。在實際的項目開發(fā)過程中，自己知道的Bug處理方法盡量全部用上，至少在個人知識層面上不要出現(xiàn)Bug，這不僅是一種工作的態(tài)度，最重要的是對整個項目負責(zé)。經(jīng)驗多了，Bug會越來越少，重點就可以集中在邏輯功能的處理上，才可以使你的代碼質(zhì)量越來越高。

　　最后一條，老生常談：我們做程序，要把用戶當(dāng)傻瓜，雖然不中聽，但是確實是一條人間正道！

it知識庫：面對Bug，程序員何去何從？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。