文章來(lái)源于公眾號(hào)：前端瓶子君 作者：jartto
一、概述
愛(ài)因斯坦曾經(jīng)說(shuō)過(guò)：「如果給我一個(gè)小時(shí)解答一道決定我生死的問(wèn)題，我會(huì)花55分鐘來(lái)弄清楚這道題到底是在問(wèn)什么。一旦清楚了它在問(wèn)什么，剩下的5分鐘足夠解答這個(gè)問(wèn)題?！?/p>
雖然我們軟件開(kāi)發(fā)過(guò)程不會(huì)面臨生死的抉擇，但是卻直接影響著用戶的使用感受，決定著產(chǎn)品的走向。所以程序員如何減少開(kāi)發(fā)中的 Bug，既反映了代碼質(zhì)量，也反映了個(gè)人綜合能力。
那么我們?cè)撊绾斡行У臏p少開(kāi)發(fā)中的 Bug 呢？
我覺(jué)得應(yīng)該從兩方面說(shuō)起：業(yè)務(wù)層和代碼層。
二、業(yè)務(wù)層
軟件開(kāi)發(fā)過(guò)程我們就不細(xì)說(shuō)了，直接來(lái)看最重要的幾個(gè)節(jié)點(diǎn)：
1.需求討論階段 一定要明確需求，測(cè)試，開(kāi)發(fā)，產(chǎn)品三方務(wù)必達(dá)成一致。前期如果存在沒(méi)有明確的問(wèn)題，那么后期就會(huì)造成無(wú)效返工和不必要的爭(zhēng)執(zhí)，這在日常開(kāi)發(fā)尤為常見(jiàn)。
所以，軟件開(kāi)發(fā)前期，我們都會(huì)進(jìn)行「評(píng)審，反講，評(píng)估」三個(gè)階段。
2.開(kāi)發(fā)完成階段 開(kāi)發(fā)完成后，程序員首先要完成「自測(cè)」，也就是軟件開(kāi)發(fā)中的「冒煙測(cè)試」，確保主流程無(wú)誤。否則，在開(kāi)發(fā)工程師提交代碼后，測(cè)試工程師步履維艱，無(wú)法有效開(kāi)展測(cè)試，會(huì)造成極大的資源浪費(fèi)。
更規(guī)范的流程需要測(cè)試工程師在需求明確之后寫(xiě)出「測(cè)試用例」，開(kāi)發(fā)工程師在完成開(kāi)發(fā)后，自行對(duì)照「測(cè)試用例」完成初步驗(yàn)證，之后就可以代碼提測(cè)了。
這么做的好處就是既保證了「高質(zhì)量的代碼交付」，同時(shí)減少了測(cè)試工程師的工作量，我們何樂(lè)而不為呢？
3.提測(cè) 自測(cè)和提測(cè)有什么區(qū)別呢，從軟件開(kāi)發(fā)過(guò)程來(lái)看，其實(shí)開(kāi)發(fā)工程師和測(cè)試工程師其實(shí)完成了不同階段的測(cè)試：
開(kāi)發(fā)工程師「白盒測(cè)試」： 是指實(shí)際運(yùn)行被測(cè)程序，通過(guò)程序的源代碼進(jìn)行測(cè)試而不使用用戶界面。這種類型的測(cè)試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法、溢出、路徑和條件等方面的缺點(diǎn)或者錯(cuò)誤，進(jìn)而加以修正。
白盒測(cè)試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點(diǎn)或者錯(cuò)誤，進(jìn)而加以修正。
測(cè)試工程師實(shí)際進(jìn)行的是「黑盒測(cè)試」。那么什么是「黑盒測(cè)試」呢？ 黑盒測(cè)試也稱功能測(cè)試，它是通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都能正常使用。在測(cè)試中，把程序看作一個(gè)不能打開(kāi)的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測(cè)試。
它只檢查程序功能是否按照需求規(guī)格說(shuō)明書(shū)的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測(cè)試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試。
黑盒測(cè)試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系出發(fā)進(jìn)行測(cè)試的。
很明顯，如果外部特性本身設(shè)計(jì)有問(wèn)題或規(guī)格說(shuō)明的規(guī)定有誤，用黑盒測(cè)試方法是發(fā)現(xiàn)不了的。黑盒測(cè)試法注重于測(cè)試軟件的功能需求，主要試圖發(fā)現(xiàn)下列幾類錯(cuò)誤。
功能不正確或遺漏；界面錯(cuò)誤；輸入和輸出錯(cuò)誤；數(shù)據(jù)庫(kù)訪問(wèn)錯(cuò)誤；性能錯(cuò)誤；初始化和終止錯(cuò)誤等；三、代碼層
代碼層面，我們需要從以下幾方面來(lái)說(shuō)起：
1.Eslint 規(guī)避低級(jí)語(yǔ)法問(wèn)題 這個(gè)顯而易見(jiàn)，編寫(xiě)代碼過(guò)程發(fā)現(xiàn)問(wèn)題，避免因?yàn)楹?jiǎn)單語(yǔ)法，如：漏寫(xiě)了逗號(hào)，變量名寫(xiě)錯(cuò)，大小寫(xiě)問(wèn)題等
2.邊界處理 做好容錯(cuò)，必要的判空，還有就是代碼邊界問(wèn)題。多想一想如果數(shù)組不存在，我們?nèi)绾翁幚?？如果?shù)組越界，我們?nèi)绾涡迯?fù)？如果數(shù)據(jù)缺失，我們?nèi)绾问鬼?yè)面不崩潰？
3.單元測(cè)試 如果時(shí)間允許，我們可以做好單元測(cè)試，每次編譯代碼，或者提測(cè)前啟動(dòng)腳本，確定測(cè)試腳本都覆蓋到了核心代碼，盡可能減少代碼出錯(cuò)率。
4.積累 為什么說(shuō)要積累，其實(shí)道理很簡(jiǎn)單。隨著開(kāi)發(fā)經(jīng)驗(yàn)的增長(zhǎng)，你可能會(huì)碰到很多問(wèn)題，那么如果細(xì)心積累，其實(shí)很多錯(cuò)誤在不知不覺(jué)中就被處理了。反之，你會(huì)不斷的掉入同一個(gè)坑里，在進(jìn)坑與出坑中迷失自我。那么我們?nèi)绾畏e累呢？
首先，碰到自己不會(huì)的問(wèn)題，如果第一時(shí)間沒(méi)有解決，通過(guò)查找或者請(qǐng)教別人解決了，那么一定要用小本本記下來(lái)，最好使用云筆記。好處不言自明。
其次，要積累自己的函數(shù)庫(kù)，我們經(jīng)常用到的一些方法，不妨自己做一個(gè)封裝，不斷沉淀。也許有一天，你會(huì)發(fā)現(xiàn)，自己不知不知覺(jué)中寫(xiě)出了一個(gè) Lodash 函數(shù)庫(kù)。
最后，你可以積累優(yōu)秀的代碼片段，嗯，「我們不生產(chǎn)代碼，只是優(yōu)秀代碼的搬運(yùn)工」。
5.學(xué)習(xí) 一句話，沒(méi)有什么比學(xué)習(xí)優(yōu)秀開(kāi)源代碼更有趣的事情了。閱讀優(yōu)秀源碼，學(xué)習(xí)作者思想，站在巨人肩膀上，你才能走的更遠(yuǎn)！
做好上面這些，相信你一定會(huì)是一位出色的工程師。
四、總結(jié)
對(duì)于這類開(kāi)放問(wèn)題仁者見(jiàn)仁，智者見(jiàn)智，我相信每個(gè)人都會(huì)有自己的看法，也會(huì)有自己一套獨(dú)特的方法。不管黑貓白貓，能抓住老鼠的就是好貓。對(duì)于程序員來(lái)說(shuō)，能減少 Bug 的方法就是好方法。
以上就是W3Cschool編程獅關(guān)于如何減少開(kāi)發(fā)中的 Bug的相關(guān)介紹了，希望對(duì)大家有所幫助。
程序員群體流傳一句話：不寫(xiě)代碼就有沒(méi)有 Bug。
我們不能因?yàn)榕路稿e(cuò)誤而減少寫(xiě)代碼，更應(yīng)該知難而上，越挫越勇。要知道日常開(kāi)發(fā)中 「Bug 是不可避免的，只能減少」。
當(dāng)然，這不應(yīng)該成為我們寫(xiě)出 Bug 推脫的理由。不斷超越，方是永恒。
