前言 對于大部分程序員來說，主要的工作時間是在開發(fā)和修復BUG。 有可能修改了一個BUG，會導致幾個新BUG的產生，不斷循環(huán)。 那么，有沒有辦法能夠減少BUG，保證代碼質量，提升工作效率？ 答案是肯定的。 如果能做到，我們多出來的時間，多摸點魚，做點自己喜歡的事情，不香嗎？ 這篇文章跟大家一起聊聊減
對于大部分程序員來說，主要的工作時間是在開發(fā)和修復BUG。
有可能修改了一個BUG，會導致幾個新BUG的產生，不斷循環(huán)。
那么，有沒有辦法能夠減少BUG，保證代碼質量，提升工作效率？
答案是肯定的。
如果能做到，我們多出來的時間，多摸點魚，做點自己喜歡的事情，不香嗎？
這篇文章跟大家一起聊聊減少代碼BUG的10個小技巧，希望對你會有所幫助。
在日常工作中，找一款好用的開發(fā)工具，對于開發(fā)人員來說非常重要。
不光可以提升開發(fā)效率，更重要的是它可以幫助我們減少BUG。
有些好的開發(fā)工具，比如：
idea
中，對于包沒有引入，會在相關的類上面
標紅
。
并且idea還有
自動補全
的功能，可以有效減少我們在日常開發(fā)的過程中，有些單詞手動輸入的時候敲錯的情況發(fā)生。
Findbugs是一款Java靜態(tài)代碼分析工具，它專注于尋找真正的缺陷或者潛在的性能問題，它可以幫助java工程師提高代碼質量以及排除隱含的缺陷。
Findbugs運用Apache BCEL 庫分析類文件，而不是源代碼，將字節(jié)碼與一組缺陷模式進行對比以發(fā)現(xiàn)可能的問題。
可以直接在idea中安裝FindBugs插件：
之后可以選擇分析哪些代碼：
分析結果：
點擊對應的問題項，可以找到具體的代碼行，進行修復。
Findbugs的檢測器已增至300多條，被分為不同的類型，常見的類型如下：
Correctness：這種歸類下的問題在某種情況下會導致bug，比如錯誤的強制類型轉換等。
Bad practice：這種類別下的代碼違反了公認的最佳實踐標準，比如某個類實現(xiàn)了equals方法但未實現(xiàn)hashCode方法等。
Multithreaded correctness：關注于同步和多線程問題。
Performance：潛在的性能問題。
Security：安全相關。
Dodgy：Findbugs團隊認為該類型下的問題代碼導致bug的可能性很高。
CheckStyle作為檢驗代碼規(guī)范的插件，除了可以使用配置默認給定的開發(fā)規(guī)范，如Sun、Google的開發(fā)規(guī)范之外，還可以使用像阿里的開發(fā)規(guī)范的插件。
目前國內用的比較多的是阿里的代碼開發(fā)規(guī)范，我們可以直接通過idea下載插件：
如果想檢測某個文件：
可以看到結果：
阿里巴巴規(guī)約掃描包括：
Alibaba Java Coding Guidelines 專注于Java代碼規(guī)范，目的是讓開發(fā)者更加方便、快速規(guī)范代碼格式。
該插件在掃描代碼后，將不符合規(guī)約的代碼按 Blocker、Critical、Major 三個等級顯示出來，并且大部分可以自動修復。
它還基于Inspection機制提供了實時檢測功能，編寫代碼的同時也能快速發(fā)現(xiàn)問題。
最近就業(yè)形式比較困難，為了感謝各位小伙伴對蘇三一直以來的支持，我特地創(chuàng)建了一些工作內推群， 看看能不能幫助到大家。
你可以在群里發(fā)布招聘信息，也可以內推工作，也可以在群里投遞簡歷找工作，也可以在群里交流面試或者工作的話題。
進群方式，添加蘇三的私人微信：su_san_java，備注：博客園+所在城市，即可加入。
SonarQube是一種自動代碼審查工具，用于檢測代碼中的錯誤，漏洞和代碼格式上的問題。
它可以與用戶現(xiàn)有的工作流程集成，以實現(xiàn)跨項目分支和提取請求的連續(xù)代碼檢查，同時也提供了可視化的管理頁面，用于查看檢測出的結果。
SonarQube通過配置的代碼分析規(guī)則，從可靠性、安全性、可維護性、覆蓋率、重復率等方面分析項目，風險等級從A~E劃分為5個等級；
同時，SonarQube可以集成pmd、findbugs、checkstyle等插件來擴展使用其他規(guī)則來檢驗代碼質量。
一般推薦它跟Jenkins集成，做成每天定時掃描項目中test分支中的代碼問題。
Fortify 是一款廣泛使用的靜態(tài)應用程序安全測試（SAST）工具。
它具有代碼掃描、漏斗掃描和滲透測試等功能。它的設計目的是有效地檢測和定位源代碼中的漏洞。
它能幫助開發(fā)人員識別和修復代碼中的安全漏洞。
Fortify的主要功能：
靜態(tài)代碼分析：它會對源代碼進行靜態(tài)分析，找出可能導致安全漏洞的代碼片段。它能識別多種類型的安全漏洞，如 SQL 注入、跨站腳本（XSS）、緩沖區(qū)溢出等。
數據流分析：它不僅分析單個代碼文件，還跟蹤應用程序的數據流。這有助于找到更復雜的漏洞，如未經驗證的用戶輸入在應用程序中的傳播路徑。
漏洞修復建議：發(fā)現(xiàn)潛在的安全漏洞時，它會為開發(fā)人員提供修復建議。
集成支持：它可以與多種持續(xù)集成（CI）工具（如 Jenkins）和應用生命周期管理（ALM）工具（如 Jira）集成，實現(xiàn)自動化的代碼掃描和漏洞跟蹤。
報告和度量：它提供了豐富的報告功能，幫助團隊了解項目的安全狀況和漏洞趨勢。
使用Fortify掃描代碼的結果：
一般推薦它跟Jenkins集成，定期掃描項目中test分支中的代碼安全問題。
有些小伙伴可能會問：寫單元測試可以減少代碼的BUG？
答案是肯定的。
我之前有同事，使用的測試驅動開發(fā)模式，開發(fā)一個功能模塊之前，先把單元測試寫好，然后再真正的開發(fā)業(yè)務代碼。
后面發(fā)現(xiàn)他寫的代碼速度很快，而且代碼質量很高，是一個開發(fā)牛人。
如果你后期要做系統(tǒng)的代碼重構，你只是重寫了相關的業(yè)務代碼，但業(yè)務邏輯并沒有修改。
這時，因為有了之前寫好的單位測試，你會發(fā)現(xiàn)測試起來非常方便。
可以幫你減少很多BUG。
功能自測，是程序員的基本要求。
但有些程序員自測之后，BUG還是比較多，而有些程序員自測之后，BUG非常少，這是什么原因呢？
可能有些人比較粗心，有些人比較細心。
其實更重要的是測試的策略。
有些人喜歡把所有相關的功能都開發(fā)完，然后一起測試。
這種情況下，相當于一個黑盒測試，需要花費大量的時間，梳理業(yè)務邏輯才能測試完整，大部分情況下，開發(fā)人員是沒法測試完整的，可能會有很多bug測試不出來。
這種做法是沒有經過單元測試，直接進行了集成測試。
看似節(jié)省了很多單元測試的時間，但其實后面修復BUG的時間可能會花費更多。
比較推薦的自測方式是：一步一個腳印。
比如：你寫了一個工具類的一個方法，就測試一下。如果這個方法中，調用了另外一個關鍵方法，我們可以先測試一下這個關鍵方法。
這樣可以寫出BUG更少的代碼。
最近就業(yè)形式比較困難，為了感謝各位小伙伴對蘇三一直以來的支持，我特地創(chuàng)建了一些工作內推群， 看看能不能幫助到大家。
你可以在群里發(fā)布招聘信息，也可以內推工作，也可以在群里投遞簡歷找工作，也可以在群里交流面試或者工作的話題。
進群方式，添加蘇三的私人微信：su_san_java，備注：博客園+所在城市，即可加入。
有些公司引入了自動化測試的功能。
每天都會自動測試，保證系統(tǒng)的核心流程沒有問題。
因為我們的日常開發(fā)中，經常需要調整核心流程的代碼。
不可能每調整一次，都需要把所有的核心流程都測試一遍吧，這樣會浪費大量的時間，而且也容易遺漏一些細節(jié)。
如果引入了自動化測試的功能，可以幫助我們把核心流程都測試一下。
避免代碼重構，或者修改核心流程，測試時間不夠，或者測試不完全的尷尬。
自動化測試，可以有效的減少核心流程調整，或者代碼重構中的BUG。
很多公司都有代碼review機制。
我之前也參與多次代碼review的會議，發(fā)現(xiàn)代碼review確實可以找出很多BUG。
比如：一些代碼的邏輯錯誤，語法的問題，不規(guī)范的命名等。
這樣問題通過組內的代碼review一般可以檢查出來。
有些國外的大廠，采用
結對編程
的模式。
同一個組的兩個人A和B一起開發(fā)，開發(fā)完之后，A reivew B的代碼，同時B review A的代碼。
因為同組的A和B對項目比較熟，對對方開發(fā)的功能更有了解，可以快速找出對外代碼中的一些問題。
能夠有效減少一些BUG。
如果你想減少日常工作中的代碼BUG，或者線上事故，少犯錯，少踩坑。
經�？磩e人真實的踩坑分享，是一個非常不錯的選擇，可以學到一些別人的工作經驗，幫助你少走很多彎路。
網上有許多博主寫過自己的踩坑記錄，大家可以上網搜一下。
也可以看看我自己總結的《 程序員最常見的100個問題 》，里面有非常詳細的記錄，干貨很多，還是非常值得一看的。
最后說一句，本文總結了10種減少代碼BUG的小技巧，但我們要根據實際情況選擇使用，并非所有的場景都適合。
如果這篇文章對您有所幫助，或者有所啟發(fā)的話，幫忙掃描下發(fā)二維碼關注一下，您的支持是我堅持寫作最大的動力。
求一鍵三連：點贊、轉發(fā)、在看。
關注蘇三的公眾號：【蘇三說技術】，在公眾號中回復：面試、代碼神器、開發(fā)手冊、時間管理有超贊的粉絲福利，另外回復：加群，可以跟很多BAT大廠的前輩交流和學習。
