周會上同事拋出了一個問題，程序員如何減少開發(fā)中的 Bug?很有意思的一個話題，本篇文章我們來進行探討與總結(jié)。

[[274809]]

一、概述

愛因斯坦曾經(jīng)說過：「如果給我一個小時解答一道決定我生死的問題，我會花55分鐘來弄清楚這道題到底是在問什么。一旦清楚了它在問什么，剩下的5分鐘足夠解答這個問題?！?/p>

雖然我們軟件開發(fā)過程不會面臨生死的抉擇，但是卻直接影響著用戶的使用感受，決定著產(chǎn)品的走向。所以程序員如何減少開發(fā)中的 Bug，既反映了代碼質(zhì)量，也反映了個人綜合能力。

那么我們該如何有效的減少開發(fā)中的 Bug 呢?

我覺得應(yīng)該從兩方面說起：業(yè)務(wù)層和代碼層。

二、業(yè)務(wù)層

軟件開發(fā)過程我們就不細說了，直接來看最重要的幾個節(jié)點：

1.需求討論階段

一定要明確需求，測試，開發(fā)，產(chǎn)品三方務(wù)必達成一致。前期如果存在沒有明確的問題，那么后期就會造成無效返工和不必要的爭執(zhí)，這在日常開發(fā)尤為常見。

所以，軟件開發(fā)前期，我們都會進行「評審，反講，評估」三個階段。

2.開發(fā)完成階段

開發(fā)完成后，程序員首先要完成「自測」，也就是軟件開發(fā)中的「冒煙測試」，確保主流程無誤。否則，在開發(fā)工程師提交代碼后，測試工程師步履維艱，無法有效開展測試，會造成極大的資源浪費。

更規(guī)范的流程需要測試工程師在需求明確之后寫出「測試用例」，開發(fā)工程師在完成開發(fā)后，自行對照「測試用例」完成初步驗證，之后就可以代碼提測了。

這么做的好處就是既保證了「高質(zhì)量的代碼交付」，同時減少了測試工程師的工作量，我們何樂而不為呢?

3.提測

自測和提測有什么區(qū)別呢，從軟件開發(fā)過程來看，其實開發(fā)工程師和測試工程師其實完成了不同階段的測試：

開發(fā)工程師「白盒測試」：

• 是指實際運行被測程序，通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法、溢出、路徑和條件等方面的缺點或者錯誤，進而加以修正。

白盒測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。

測試工程師實際進行的是「黑盒測試」。那么什么是「黑盒測試」呢?

黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進行測試。

它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進行測試。

黑盒測試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系出發(fā)進行測試的。

很明顯，如果外部特性本身設(shè)計有問題或規(guī)格說明的規(guī)定有誤，用黑盒測試方法是發(fā)現(xiàn)不了的。黑盒測試法注重于測試軟件的功能需求，主要試圖發(fā)現(xiàn)下列幾類錯誤。

• 功能不正確或遺漏;
• 界面錯誤;
• 輸入和輸出錯誤;
• 數(shù)據(jù)庫訪問錯誤;
• 性能錯誤;
• 初始化和終止錯誤等;

三、代碼層

代碼層面，我們需要從以下幾方面來說起：

1.Eslint 規(guī)避低級語法問題

這個顯而易見，編寫代碼過程發(fā)現(xiàn)問題，避免因為簡單語法，如：漏寫了逗號，變量名寫錯，大小寫問題等

2.邊界處理

做好容錯，必要的判空，還有就是代碼邊界問題。多想一想如果數(shù)組不存在，我們?nèi)绾翁幚?如果數(shù)組越界，我們?nèi)绾涡迯?fù)?如果數(shù)據(jù)缺失，我們?nèi)绾问鬼撁娌槐罎?

3.單元測試

如果時間允許，我們可以做好單元測試，每次編譯代碼，或者提測前啟動腳本，確定測試腳本都覆蓋到了核心代碼，盡可能減少代碼出錯率。

4.積累

為什么說要積累，其實道理很簡單。隨著開發(fā)經(jīng)驗的增長，你可能會碰到很多問題，那么如果細心積累，其實很多錯誤在不知不覺中就被處理了。反之，你會不斷的掉入同一個坑里，在進坑與出坑中迷失自我。那么我們?nèi)绾畏e累呢?

• 首先，碰到自己不會的問題，如果第一時間沒有解決，通過查找或者請教別人解決了，那么一定要用小本本記下來，最好使用云筆記。好處不言自明。
• 其次，要積累自己的函數(shù)庫，我們經(jīng)常用到的一些方法，不妨自己做一個封裝，不斷沉淀。也許有一天，你會發(fā)現(xiàn)，自己不知不知覺中寫出了一個 Lodash 函數(shù)庫。
• 最后，你可以積累優(yōu)秀的代碼片段，嗯，「我們不生產(chǎn)代碼，只是優(yōu)秀代碼的搬運工」。

5.學習

一句話，沒有什么比學習優(yōu)秀開源代碼更有趣的事情了。閱讀優(yōu)秀源碼，學習作者思想，站在巨人肩膀上，你才能走的更遠!

做好上面這些，相信你一定會是一位出色的工程師。

四、總結(jié)

對于這類開放問題仁者見仁，智者見智，我相信每個人都會有自己的看法，也會有自己一套獨特的方法。不管黑貓白貓，能抓住老鼠的就是好貓。對于程序員來說，能減少 Bug 的方法就是好方法。

程序員群體流傳一句話：不寫代碼就有沒有 Bug。

我們不能因為怕犯錯誤而減少寫代碼，更應(yīng)該知難而上，越挫越勇。要知道日常開發(fā)中 「Bug 是不可避免的，只能減少」。

當然，這不應(yīng)該成為我們寫出 Bug 推脫的理由。不斷超越，方是永恒。

版權(quán)聲明：

文章首發(fā)于 Jartto's blog ， 轉(zhuǎn)載文章請務(wù)必以超鏈接形式標明文章出處，作者信息及本版權(quán)聲明( http://jartto.wang )。