Redmi Pad評測：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍(lán)牙耳機(jī)到筆記本電腦，紅米不知不覺之間也已經(jīng)形成了自己頗有競爭力的產(chǎn)品體系，在中端和次旗艦市場上甚至要比小米新機(jī)的表現(xiàn)來得更好，正所謂“大丈夫生居
愛因斯坦曾說過：“如果我有一個(gè)小時(shí)來解決一個(gè)關(guān)系到我生死的問題，我會(huì)花55分鐘弄清楚問題是什么。一旦我知道了問題是什么，我可以在五分鐘內(nèi)解決它。”
雖然我們的軟件開發(fā)過程并不涉及生死抉擇，但它直接影響用戶體驗(yàn)，并決定產(chǎn)品的方向。因此，程序員在開發(fā)過程中如何減少 Bug 反映了代碼質(zhì)量，并展示了他們的整體能力。
那么，我們?nèi)绾卧陂_發(fā)過程中有效減少 Bug 呢？
我認(rèn)為我們應(yīng)該從兩個(gè)方面入手：業(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ò)誤：
在代碼層面，我們需要從以下幾個(gè)方面入手：
Eslint 避免低級語法問題
這顯而易見。在編碼過程中，識別問題，避免諸如逗號缺失、變量名稱錯(cuò)誤、大小寫敏感等簡單的語法錯(cuò)誤。
邊界處理
確保容錯(cuò)性，必要的空值檢查，并解決代碼邊界問題。考慮如何處理不存在的數(shù)組或數(shù)組越界等場景。如何防止頁面因數(shù)據(jù)丟失而崩潰？
單元測試
如果時(shí)間允許，進(jìn)行徹底的單元測試。在每次編譯代碼或部署之前運(yùn)行測試腳本，確保核心代碼被測試覆蓋，并盡量減少錯(cuò)誤率。
積累為什么要談積累？原因很簡單：隨著開發(fā)經(jīng)驗(yàn)的增加，可能會(huì)遇到許多問題。通過細(xì)心地積累知識，許多錯(cuò)誤可以在不知不覺中得到解決。否則，將不斷陷入同一個(gè)陷阱，并在其中迷失。那么我們?nèi)绾畏e累？
首先，當(dāng)遇到無法立即解決的問題時(shí)，如果通過研究或向他人尋求幫助解決了問題，請務(wù)必記下在筆記本中，或者更好的是使用云筆記以便隨時(shí)訪問。
其次，構(gòu)建函數(shù)庫，通過封裝常用方法進(jìn)行不斷完善。也許有一天會(huì)發(fā)現(xiàn)自己不知不覺地創(chuàng)建了自己的 Lodash 庫。
最后，積累優(yōu)秀的代碼片段；“我們不生產(chǎn)代碼，我們只是優(yōu)秀代碼的搬運(yùn)工。”
學(xué)習(xí)
簡而言之：沒有什么比從優(yōu)秀的開源代碼中學(xué)習(xí)更有趣的了！閱讀優(yōu)秀的源碼不僅可以讓我們學(xué)習(xí)作者的思想，還可以讓我們站在他們的肩膀上走得更遠(yuǎn)！
關(guān)于這樣一個(gè)開放性的問題，每個(gè)人可能會(huì)有不同的意見，智者見智。每個(gè)人都有自己的觀點(diǎn)和獨(dú)特的方法。不管是黑貓還是白貓，只要能抓住老鼠就是好貓。對于程序員來說，任何可以減少 Bug 的方法都是好方法。
程序員常說：“沒有代碼，就沒有 Bug。”
我們不應(yīng)因?yàn)楹ε路稿e(cuò)而減少編碼，而是要勇敢地面對挑戰(zhàn)，并在面對挫折時(shí)更加堅(jiān)定。重要的是要理解，Bug 在日常開發(fā)中是不可避免的，只能盡量減少。當(dāng)然，這不應(yīng)該成為我們將 Bug 歸咎于他人的借口。不斷超越自我是走向永恒的關(guān)鍵。
本文鏈接：http://m.www897cc.com/showinfo-26-97914-0.html我們一起聊聊如何在開發(fā)過程中減少 Bug？
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 主流前端框架語法和特性全面對比！
下一篇： 瞄準(zhǔn)數(shù)字化轉(zhuǎn)型主戰(zhàn)場，華為云 618 營銷季攜手中小企業(yè)加速智能化躍遷
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號