對于大部分程序員來說,主要的工作時間是在開發(fā)和修復(fù)BUG。
有可能修改了一個BUG,會導(dǎo)致幾個新BUG的產(chǎn)生,不斷循環(huán)。
那么,有沒有辦法能夠減少BUG,保證代碼質(zhì)量,提升工作效率?
答案是肯定的。
如果能做到,我們多出來的時間,多摸點魚,做點自己喜歡的事情,不香嗎?
這篇文章跟大家一起聊聊減少代碼BUG的10個小技巧,希望對你會有所幫助。
在日常工作中,找一款好用的開發(fā)工具,對于開發(fā)人員來說非常重要。
不光可以提升開發(fā)效率,更重要的是它可以幫助我們減少BUG。
有些好的開發(fā)工具,比如:idea中,對于包沒有引入,會在相關(guān)的類上面標(biāo)紅。
并且idea還有自動補全的功能,可以有效減少我們在日常開發(fā)的過程中,有些單詞手動輸入的時候敲錯的情況發(fā)生。
Findbugs是一款Java靜態(tài)代碼分析工具,它專注于尋找真正的缺陷或者潛在的性能問題,它可以幫助java工程師提高代碼質(zhì)量以及排除隱含的缺陷。
Findbugs運用Apache BCEL 庫分析類文件,而不是源代碼,將字節(jié)碼與一組缺陷模式進(jìn)行對比以發(fā)現(xiàn)可能的問題。
可以直接在idea中安裝FindBugs插件:
之后可以選擇分析哪些代碼:
分析結(jié)果:
點擊對應(yīng)的問題項,可以找到具體的代碼行,進(jìn)行修復(fù)。
Findbugs的檢測器已增至300多條,被分為不同的類型,常見的類型如下:
CheckStyle作為檢驗代碼規(guī)范的插件,除了可以使用配置默認(rèn)給定的開發(fā)規(guī)范,如Sun、Google的開發(fā)規(guī)范之外,還可以使用像阿里的開發(fā)規(guī)范的插件。
目前國內(nèi)用的比較多的是阿里的代碼開發(fā)規(guī)范,我們可以直接通過idea下載插件:
如果想檢測某個文件:
可以看到結(jié)果:
阿里巴巴規(guī)約掃描包括:
Alibaba Java Coding Guidelines 專注于Java代碼規(guī)范,目的是讓開發(fā)者更加方便、快速規(guī)范代碼格式。
該插件在掃描代碼后,將不符合規(guī)約的代碼按 Blocker、Critical、Major 三個等級顯示出來,并且大部分可以自動修復(fù)。
它還基于Inspection機制提供了實時檢測功能,編寫代碼的同時也能快速發(fā)現(xiàn)問題。
SonarQube是一種自動代碼審查工具,用于檢測代碼中的錯誤,漏洞和代碼格式上的問題。
它可以與用戶現(xiàn)有的工作流程集成,以實現(xiàn)跨項目分支和提取請求的連續(xù)代碼檢查,同時也提供了可視化的管理頁面,用于查看檢測出的結(jié)果。
SonarQube通過配置的代碼分析規(guī)則,從可靠性、安全性、可維護性、覆蓋率、重復(fù)率等方面分析項目,風(fēng)險等級從A~E劃分為5個等級;
同時,SonarQube可以集成pmd、findbugs、checkstyle等插件來擴展使用其他規(guī)則來檢驗代碼質(zhì)量。
一般推薦它跟Jenkins集成,做成每天定時掃描項目中test分支中的代碼問題。
Fortify 是一款廣泛使用的靜態(tài)應(yīng)用程序安全測試(SAST)工具。
它具有代碼掃描、漏斗掃描和滲透測試等功能。它的設(shè)計目的是有效地檢測和定位源代碼中的漏洞。
它能幫助開發(fā)人員識別和修復(fù)代碼中的安全漏洞。
Fortify的主要功能:
使用Fortify掃描代碼的結(jié)果:
一般推薦它跟Jenkins集成,定期掃描項目中test分支中的代碼安全問題。
有些小伙伴可能會問:寫單元測試可以減少代碼的BUG?
答案是肯定的。
我之前有同事,使用的測試驅(qū)動開發(fā)模式,開發(fā)一個功能模塊之前,先把單元測試寫好,然后再真正的開發(fā)業(yè)務(wù)代碼。
后面發(fā)現(xiàn)他寫的代碼速度很快,而且代碼質(zhì)量很高,是一個開發(fā)牛人。
如果你后期要做系統(tǒng)的代碼重構(gòu),你只是重寫了相關(guān)的業(yè)務(wù)代碼,但業(yè)務(wù)邏輯并沒有修改。
這時,因為有了之前寫好的單位測試,你會發(fā)現(xiàn)測試起來非常方便。
可以幫你減少很多BUG。
功能自測,是程序員的基本要求。
但有些程序員自測之后,BUG還是比較多,而有些程序員自測之后,BUG非常少,這是什么原因呢?
可能有些人比較粗心,有些人比較細(xì)心。
其實更重要的是測試的策略。
有些人喜歡把所有相關(guān)的功能都開發(fā)完,然后一起測試。
這種情況下,相當(dāng)于一個黑盒測試,需要花費大量的時間,梳理業(yè)務(wù)邏輯才能測試完整,大部分情況下,開發(fā)人員是沒法測試完整的,可能會有很多bug測試不出來。
這種做法是沒有經(jīng)過單元測試,直接進(jìn)行了集成測試。
看似節(jié)省了很多單元測試的時間,但其實后面修復(fù)BUG的時間可能會花費更多。
比較推薦的自測方式是:一步一個腳印。
比如:你寫了一個工具類的一個方法,就測試一下。如果這個方法中,調(diào)用了另外一個關(guān)鍵方法,我們可以先測試一下這個關(guān)鍵方法。
這樣可以寫出BUG更少的代碼。
有些公司引入了自動化測試的功能。
有專門的程序,每天都會自動測試,保證系統(tǒng)的核心流程沒有問題。
因為我們的日常開發(fā)中,經(jīng)常需要調(diào)整核心流程的代碼。
不可能每調(diào)整一次,都需要把所有的核心流程都測試一遍吧,這樣會浪費大量的時間,而且也容易遺漏一些細(xì)節(jié)。
如果引入了自動化測試的功能,可以幫助我們把核心流程都測試一下。
避免代碼重構(gòu),或者修改核心流程,測試時間不夠,或者測試不完全的尷尬。
自動化測試,可以有效的減少核心流程調(diào)整,或者代碼重構(gòu)中的BUG。
很多公司都有代碼review機制。
我之前也參與多次代碼review的會議,發(fā)現(xiàn)代碼review確實可以找出很多BUG。
比如:一些代碼的邏輯錯誤,語法的問題,不規(guī)范的命名等。
這樣問題通過組內(nèi)的代碼review一般可以檢查出來。
有些國外的大廠,采用結(jié)對編程的模式。
同一個組的兩個人A和B一起開發(fā),開發(fā)完之后,A reivew B的代碼,同時B review A的代碼。
因為同組的A和B對項目比較熟,對對方開發(fā)的功能更有了解,可以快速找出對外代碼中的一些問題。
能夠有效減少一些BUG。
如果你想減少日常工作中的代碼BUG,或者線上事故,少犯錯,少踩坑。
經(jīng)常看別人真實的踩坑分享,是一個非常不錯的選擇,可以學(xué)到一些別人的工作經(jīng)驗,幫助你少走很多彎路。
網(wǎng)上有許多博主寫過自己的踩坑記錄,大家可以上網(wǎng)搜一下。
最后說一句,本文總結(jié)了10種減少代碼BUG的小技巧,但我們要根據(jù)實際情況選擇使用,并非所有的場景都適合。
本文鏈接:http://www.tebozhan.com/showinfo-26-84023-0.html我用這十招,減少了80%的BUG
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 用Go語言&&Redis實現(xiàn)分布式鎖,我還是第一次
下一篇: 領(lǐng)域驅(qū)動設(shè)計(DDD)中的應(yīng)用架構(gòu):六邊形、洋蔥、整潔與清晰