愛因斯坦曾說過：“如果我有一個(gè)小時(shí)來解決一個(gè)關(guān)系到我生死的問題，我會花55分鐘弄清楚問題是什么。一旦我知道了問題是什么，我可以在五分鐘內(nèi)解決它?！?/span>

雖然我們的軟件開發(fā)過程并不涉及生死抉擇，但它直接影響用戶體驗(yàn)，并決定產(chǎn)品的方向。因此，程序員在開發(fā)過程中如何減少 Bug 反映了代碼質(zhì)量，并展示了他們的整體能力。

那么，我們?nèi)绾卧陂_發(fā)過程中有效減少 Bug 呢？

我認(rèn)為我們應(yīng)該從兩個(gè)方面入手：業(yè)務(wù)層和代碼層。

業(yè)務(wù)層

我們不詳細(xì)討論軟件開發(fā)過程，直接看最重要的關(guān)鍵點(diǎn)：

需求討論階段

在需求討論階段，必須明確需求，并使測試、開發(fā)和產(chǎn)品團(tuán)隊(duì)達(dá)成共識。如果在早期階段沒有明確的問題，后期將導(dǎo)致無效的返工和不必要的爭執(zhí)，這在日常開發(fā)中尤為常見。因此，在軟件開發(fā)的早期階段，我們將經(jīng)歷三個(gè)階段：“審查、反饋、評估”。

開發(fā)完成階段

開發(fā)完成后，程序員需要首先完成“自測”，即軟件開發(fā)中的“冒煙測試”，以確保主要流程沒有錯(cuò)誤。否則，開發(fā)工程師提交代碼后，測試工程師將難以進(jìn)行有效的測試，導(dǎo)致資源的大量浪費(fèi)。

一個(gè)更標(biāo)準(zhǔn)化的過程要求測試工程師在明確需求后編寫“測試用例”。開發(fā)完成后，開發(fā)人員可以自行對照“測試用例”進(jìn)行初步驗(yàn)證，然后提交代碼進(jìn)行測試。

這樣做的好處不僅是確?！案哔|(zhì)量的代碼交付”，還可以減少測試工程師的工作量。為什么不這樣做呢？

代碼提交測試階段

自測和代碼提交測試有什么區(qū)別？從軟件開發(fā)的角度來看，開發(fā)人員和測試人員在不同的階段進(jìn)行測試：

開發(fā)人員的“白盒測試”：

白盒測試是指通過使用源代碼進(jìn)行測試，而不使用用戶界面來運(yùn)行測試程序。這種測試需要通過代碼的語法分析發(fā)現(xiàn)與算法、溢出、路徑、條件等相關(guān)的內(nèi)部編碼缺陷或錯(cuò)誤，然后進(jìn)行修正。

測試工程師進(jìn)行“黑盒測試”：

黑盒測試，也稱為功能測試，是通過測試來檢測每個(gè)功能是否可以正常使用。在測試中，程序被視為一個(gè)不能打開的黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和特性，只對程序接口進(jìn)行測試。

黑盒測試只檢查程序功能是否按照需求規(guī)范文檔正常使用，程序能否正確接收輸入數(shù)據(jù)并生成正確的輸出信息。黑盒測試關(guān)注外部程序結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件接口和軟件功能進(jìn)行測試。

黑盒測試是一種從用戶角度出發(fā)，以輸入數(shù)據(jù)和輸出數(shù)據(jù)之間的對應(yīng)關(guān)系為起點(diǎn)進(jìn)行的測試。

顯然，如果外部特性的設(shè)計(jì)有問題或規(guī)范有錯(cuò)誤，使用黑盒測試方法是無法發(fā)現(xiàn)的。黑盒測試主要針對軟件的功能需求，主要試圖發(fā)現(xiàn)以下類型的錯(cuò)誤：

• 功能不正確或缺失；
• 接口錯(cuò)誤；
• 輸入和輸出錯(cuò)誤；
• 數(shù)據(jù)庫訪問錯(cuò)誤；
• 性能錯(cuò)誤；
• 初始化和終止錯(cuò)誤。

代碼層

在代碼層面，我們需要從以下幾個(gè)方面入手：

Eslint 避免低級語法問題

這顯而易見。在編碼過程中，識別問題，避免諸如逗號缺失、變量名稱錯(cuò)誤、大小寫敏感等簡單的語法錯(cuò)誤。

邊界處理

確保容錯(cuò)性，必要的空值檢查，并解決代碼邊界問題?？紤]如何處理不存在的數(shù)組或數(shù)組越界等場景。如何防止頁面因數(shù)據(jù)丟失而崩潰？

單元測試

如果時(shí)間允許，進(jìn)行徹底的單元測試。在每次編譯代碼或部署之前運(yùn)行測試腳本，確保核心代碼被測試覆蓋，并盡量減少錯(cuò)誤率。

積累為什么要談積累？原因很簡單：隨著開發(fā)經(jīng)驗(yàn)的增加，可能會遇到許多問題。通過細(xì)心地積累知識，許多錯(cuò)誤可以在不知不覺中得到解決。否則，將不斷陷入同一個(gè)陷阱，并在其中迷失。那么我們?nèi)绾畏e累？

首先，當(dāng)遇到無法立即解決的問題時(shí)，如果通過研究或向他人尋求幫助解決了問題，請務(wù)必記下在筆記本中，或者更好的是使用云筆記以便隨時(shí)訪問。

其次，構(gòu)建函數(shù)庫，通過封裝常用方法進(jìn)行不斷完善。也許有一天會發(fā)現(xiàn)自己不知不覺地創(chuàng)建了自己的 Lodash 庫。

最后，積累優(yōu)秀的代碼片段；“我們不生產(chǎn)代碼，我們只是優(yōu)秀代碼的搬運(yùn)工?！?/strong>

學(xué)習(xí)

簡而言之：沒有什么比從優(yōu)秀的開源代碼中學(xué)習(xí)更有趣的了！閱讀優(yōu)秀的源碼不僅可以讓我們學(xué)習(xí)作者的思想，還可以讓我們站在他們的肩膀上走得更遠(yuǎn)！

結(jié)語

關(guān)于這樣一個(gè)開放性的問題，每個(gè)人可能會有不同的意見，智者見智。每個(gè)人都有自己的觀點(diǎn)和獨(dú)特的方法。不管是黑貓還是白貓，只要能抓住老鼠就是好貓。對于程序員來說，任何可以減少 Bug 的方法都是好方法。

程序員常說：“沒有代碼，就沒有 Bug?！?/p>

我們不應(yīng)因?yàn)楹ε路稿e(cuò)而減少編碼，而是要勇敢地面對挑戰(zhàn)，并在面對挫折時(shí)更加堅(jiān)定。重要的是要理解，Bug 在日常開發(fā)中是不可避免的，只能盡量減少。當(dāng)然，這不應(yīng)該成為我們將 Bug 歸咎于他人的借口。不斷超越自我是走向永恒的關(guān)鍵。