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