程序員如何減少開發中的 Bug?

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

一、概述

愛因斯坦曾經說過:「如果給我一個小時解答一道決定我生死的問題,我會花55分鐘來弄清楚這道題到底是在問什麼。一旦清楚了它在問什麼,剩下的5分鐘足夠解答這個問題。」

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

那麼我們該如何有效的減少開發中的 Bug 呢?

我覺得應該從兩方面說起:業務層和代碼層。

二、業務層

軟件開發過程我們就不細說了,直接來看最重要的幾個節點:

1.需求討論階段

一定要明確需求,測試,開發,產品三方務必達成一致。前期如果存在沒有明確的問題,那麼後期就會造成無效返工和不必要的爭執,這在日常開發尤爲常見。

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

2.開發完成階段

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

更規範的流程需要測試工程師在需求明確之後寫出「測試用例」,開發工程師在完成開發後,自行對照「測試用例」完成初步驗證,之後就可以代碼提測了。

這麼做的好處就是既保證了「高質量的代碼交付」,同時減少了測試工程師的工作量,我們何樂而不爲呢?

3.提測

自測和提測有什麼區別呢,從軟件開發過程來看,其實開發工程師和測試工程師其實完成了不同階段的測試:

開發工程師「白盒測試」:

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

白盒測試需要從代碼句法發現內部代碼在算法,溢出,路徑,條件等等中的缺點或者錯誤,進而加以修正。

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

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

它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進行測試。

黑盒測試是以用戶的角度,從輸入數據與輸出數據的對應關係出發進行測試的。

很明顯,如果外部特性本身設計有問題或規格說明的規定有誤,用黑盒測試方法是發現不了的。黑盒測試法注重於測試軟件的功能需求,主要試圖發現下列幾類錯誤。

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

三、代碼層

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

1.Eslint 規避低級語法問題

這個顯而易見,編寫代碼過程發現問題,避免因爲簡單語法,如:漏寫了逗號,變量名寫錯,大小寫問題等

2.邊界處理

做好容錯,必要的判空,還有就是代碼邊界問題。多想一想如果數組不存在,我們如何處理?如果數組越界,我們如何修復?如果數據缺失,我們如何使頁面不崩潰?

3.單元測試

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

4.積累

爲什麼說要積累,其實道理很簡單。隨着開發經驗的增長,你可能會碰到很多問題,那麼如果細心積累,其實很多錯誤在不知不覺中就被處理了。反之,你會不斷的掉入同一個坑裏,在進坑與出坑中迷失自我。那麼我們如何積累呢?

  • 首先,碰到自己不會的問題,如果第一時間沒有解決,通過查找或者請教別人解決了,那麼一定要用小本本記下來,最好使用雲筆記。好處不言自明。
  • 其次,要積累自己的函數庫,我們經常用到的一些方法,不妨自己做一個封裝,不斷沉澱。也許有一天,你會發現,自己不知不知覺中寫出了一個 Lodash 函數庫。
  • 最後,你可以積累優秀的代碼片段,嗯,「我們不生產代碼,只是優秀代碼的搬運工」。

5.學習

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

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

四、總結

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

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

我們不能因爲怕犯錯誤而減少寫代碼,更應該知難而上,越挫越勇。要知道日常開發中 「Bug 是不可避免的,只能減少」。

當然,這不應該成爲我們寫出 Bug 推脫的理由。不斷超越,方是永恆。

版權聲明:

文章首發於 Jartto's blog , 轉載文章請務必以超鏈接形式標明文章出處,作者信息及本版權聲明( http://jartto.wang )。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章