前言

大家好，我是田螺。

我們開(kāi)發(fā)完需求，提測(cè)前，一般都需要代碼評(píng)審。小伙伴們，你們知道代碼評(píng)審，一般都有哪些軍規(guī)嘛？今天田螺哥給你帶來(lái)代碼評(píng)審的18個(gè)軍規(guī)。

1. 添加必要的注釋

其實(shí)，寫(xiě)代碼的時(shí)候，沒(méi)有必要寫(xiě)太多的注釋，因?yàn)楹玫姆椒⒆兞棵褪亲詈玫淖⑨尅Ｒ韵戮褪枪P者總結(jié)的一些注釋規(guī)范：

• 所有的類都必須添加創(chuàng)建者和創(chuàng)建日期，以及簡(jiǎn)單的注釋描述
• 方法內(nèi)部的復(fù)雜業(yè)務(wù)邏輯或者算法，需要添加清楚的注釋
• 一般情況下，注釋描述類、方法、變量的作用
• 任何需要提醒的警告或TODO，也要注釋清楚
• 如果是注釋一行代碼的，就用//;如果注釋代碼塊或者接口方法的，有多行/* **/
• 一塊代碼邏輯如果你站在一個(gè)陌生人的角度去看,第一遍看不懂的話,就需要添加注釋了

以下就是一些添加注釋的demo：

/**
 * @author 田螺
 * @date 2023/04/22 5:20 PM
 * @desc 田螺的實(shí)現(xiàn)類，撿田螺、賣田螺 （更多干貨，關(guān)注公眾號(hào)：撿田螺的小男孩）
 */
public class TianLuoClass {
 
    /**
     * 這是賣田螺的兩法，它將兩個(gè)田螺的價(jià)格整數(shù)相加并返回結(jié)果。
     * 
     * @param x 第一個(gè)整數(shù)
     * @param y 第二個(gè)整數(shù)
     * @return 兩個(gè)整數(shù)的和
     */
    public int sellTianLuo(int x, int y) {
        return x + y;
    }
}

2.日志打印規(guī)范

日志是快速定位問(wèn)題的好幫手，是撕逼和甩鍋的利器！打印好日志非常重要。如果代碼評(píng)審的時(shí)候，這些日志規(guī)范沒(méi)遵守，就需要修改：

• 日志級(jí)別選擇不對(duì)。常見(jiàn)的日志級(jí)別有error、warn、info、debug四種，不要反手就是info哈
• 日志沒(méi)打印出調(diào)用方法的入?yún)⒑晚憫?yīng)結(jié)果，尤其是跨系統(tǒng)調(diào)用的時(shí)候。
• 業(yè)務(wù)日志沒(méi)包含關(guān)鍵參數(shù),如userId,bizSeq等等,不方便問(wèn)題排查
• 如果日志包含關(guān)鍵信息，比如手機(jī)號(hào)、身份證等，需要脫敏處理
• 一些不符合預(yù)期的情況，如一些未知異常（數(shù)據(jù)庫(kù)的數(shù)據(jù)異常等），又或者不符合業(yè)務(wù)預(yù)期的特殊場(chǎng)景，都需要打印相關(guān)的日志

對(duì)于日志打印規(guī)范，我之前整理出一篇文章，大家可以看一下哈，挺有用的：

工作總結(jié)！日志打印的15個(gè)建議

3. 命名規(guī)范

Java代碼的命名應(yīng)該清晰、簡(jiǎn)潔和易于理解。我們代碼評(píng)審的時(shí)候，要注意是否有命名不規(guī)范，不清晰的代碼。下面是一些命名規(guī)范的建議：

• 類和接口應(yīng)該使用首字母大寫(xiě)的駝峰命名法
• 方法和變量應(yīng)該使用小寫(xiě)的駝峰命名法
• 常量應(yīng)該使用全大寫(xiě)字母和下劃線
• 開(kāi)發(fā)者是不是選擇易于理解的名稱給變量、類和方法進(jìn)行命名

4.參數(shù)校驗(yàn)

我們代碼評(píng)審的時(shí)候，要注意參數(shù)是否都做了校驗(yàn)，如userId非空檢查、金額范圍檢查、userName長(zhǎng)度校驗(yàn)等等。一般我們?cè)谔幚順I(yè)務(wù)邏輯的時(shí)候，要遵循先檢查、后處理的原則。

如果你的數(shù)據(jù)庫(kù)字段userName設(shè)置為varchar(16),對(duì)方傳了一個(gè)32位的字符串過(guò)來(lái)，你不校驗(yàn)參數(shù)，插入數(shù)據(jù)庫(kù)直接異常了。

很多bug都是因?yàn)闆](méi)做參數(shù)校驗(yàn)造成的，這一軍規(guī)，是代碼評(píng)審重點(diǎn)關(guān)注的哈：

5. 判空處理

• 獲取對(duì)象的屬性時(shí)，都要判空處理。要不然很多時(shí)候會(huì)出現(xiàn)空指針異常。

if(object!=null){
   String name = object.getName();
}

如果你要遍歷列表，也需要判空

6. 異常處理規(guī)范

良好的異常處理可以確保代碼的可靠性和可維護(hù)性。因此，異常處理也是代碼評(píng)審的一項(xiàng)重要規(guī)范。以下是一些異常處理的建議：

• 不要捕獲通用的Exception異常，而應(yīng)該盡可能捕獲特定的異常
• 在捕獲異常時(shí)，應(yīng)該記錄異常信息以便于調(diào)試
• 內(nèi)部異常要確認(rèn)最終的處理方式，避免未知異常當(dāng)作失敗處理。
• 在finally塊中釋放資源，或者使用try-with-resource
• 不要使用e.printStackTrace(),而是使用log打印。
• catch了異常，要打印出具體的exception，否則無(wú)法更好定位問(wèn)題
• 捕獲異常與拋出異常必須是完全匹配，或者捕獲異常是拋異常的父類
• 捕獲到的異常，不能忽略它，要打印相對(duì)應(yīng)的日志
• 注意異常對(duì)你的代碼層次結(jié)構(gòu)的侵染（早發(fā)現(xiàn)早處理）
• 自定義封裝異常，不要丟棄原始異常的信息Throwable cause
• 注意異常匹配的順序，優(yōu)先捕獲具體的異常
• 對(duì)外提供APi時(shí)，要提供對(duì)應(yīng)的錯(cuò)誤碼
• 系統(tǒng)內(nèi)部應(yīng)該拋出有業(yè)務(wù)含義的自定義異常，而不是直接拋出RuntimeException，或者直接拋出Exception\Throwable。

大家有興趣可以看下之前我的這篇文章哈：Java 異常處理的十個(gè)建議

7. 模塊化，可擴(kuò)展性

代碼評(píng)審的時(shí)候，關(guān)注一下，代碼編寫(xiě)設(shè)計(jì)是否滿足模塊話，接口是否具有可擴(kuò)展性

比如你的需求是醬紫：是用戶添加或者修改員工時(shí)，需要刷臉。那你是反手提供一個(gè)員工管理的提交刷臉信息接口？還是先思考：提交刷臉是不是通用流程呢？比如轉(zhuǎn)賬或者一鍵貼現(xiàn)需要接入刷臉的話，你是否需要重新實(shí)現(xiàn)一個(gè)接口呢？還是當(dāng)前按業(yè)務(wù)類型劃分模塊，復(fù)用這個(gè)接口就好，保留接口的可擴(kuò)展性。

如果按模塊劃分的話，未來(lái)如果其他場(chǎng)景比如一鍵貼現(xiàn)接入刷臉的話，不用再搞一套新的接口，只需要新增枚舉，然后復(fù)用刷臉通過(guò)流程接口，實(shí)現(xiàn)一鍵貼現(xiàn)刷臉的差異化即可。

8. 并發(fā)控制規(guī)范

• 在使用并發(fā)集合時(shí)，應(yīng)該注意它們的線程安全性和并發(fā)性能,如ConcurrentHashMap是線性安全的,HashMap就是非線性安全的
• 樂(lè)觀鎖,悲觀鎖防止數(shù)據(jù)庫(kù)并發(fā).樂(lè)觀鎖一般用版本號(hào)version控制,悲觀鎖一般用select …for update
• 如果是單實(shí)例的多線程并發(fā)處理,一般通過(guò)Java鎖機(jī)制,比如sychronized ,reentrantlock
• 如果是同一集群的多線程并發(fā)處理,可以用Redis分布式鎖或者走zookeeper
• 如果是跨集群的多線程并發(fā)處理,則考慮數(shù)據(jù)庫(kù)實(shí)現(xiàn)的分布式鎖。
• 在使用分布式鎖的時(shí)候,要注意有哪些坑,比如redis一些經(jīng)典的坑.

至于分布式鎖,大家可以看下我之前的這幾篇文章哈

• Redis分布式鎖的10個(gè)坑
• 面試必備：聊聊分布式鎖的多種實(shí)現(xiàn)！

9. 單元測(cè)試規(guī)范

• 測(cè)試類的命名,一般以測(cè)試的類+Test,如:CalculatorTest.
• 測(cè)試方法的命名,一般以test開(kāi)頭+ 測(cè)試的方法,如testAdd.
• 單測(cè)行覆蓋率一般要求大于75%.
• 單測(cè)一般要求包含主流程用例、參數(shù)邊界值等校驗(yàn)用例
• 單測(cè)一般也要求包含中間件訪問(wèn)超時(shí)、返回空、等異常的用例,比如訪問(wèn)數(shù)據(jù)庫(kù)或者Redis異常.
• 單測(cè)用例要求包含并發(fā)、防重、冪等等用例.

10. 代碼格式規(guī)范

良好的代碼格式，可以使代碼更容易閱讀和理解。下面是一些常見(jiàn)的代碼格式化建議：

• 縮進(jìn)使用四個(gè)空格
• 代碼塊使用花括號(hào)分隔
• 每行不超過(guò)80個(gè)字符
• 每個(gè)方法應(yīng)該按照特定的順序排列，例如：類變量、實(shí)例變量、構(gòu)造函數(shù)、公共方法、私有方法等。

11. 接口兼容性

代碼評(píng)審的時(shí)候,要重點(diǎn)關(guān)注是否考慮到了接口的兼容性.因?yàn)楹芏郻ug都是因?yàn)樾薷牧藢?duì)外舊接口，但是卻不做兼容導(dǎo)致的。關(guān)鍵這個(gè)問(wèn)題多數(shù)是比較嚴(yán)重的，可能直接導(dǎo)致系統(tǒng)發(fā)版失敗的。新手程序員很容易犯這個(gè)錯(cuò)誤哦~

所以，如果你的需求是在原來(lái)接口上修改，尤其這個(gè)接口是對(duì)外提供服務(wù)的話，一定要考慮接口兼容。舉個(gè)例子吧，比如dubbo接口，原本是只接收A，B參數(shù)，現(xiàn)在你加了一個(gè)參數(shù)C，就可以考慮這樣處理：

//老接口
void oldService(A,B){
  //兼容新接口，傳個(gè)null代替C
  newService(A,B,null);
}

//新接口，暫時(shí)不能刪掉老接口，需要做兼容。
void newService(A,B,C){
  ...
}

12. 程序邏輯是否清晰,主次是否夠分明

代碼評(píng)審的時(shí)候，要關(guān)注程序邏輯是否清晰。比如，你的一個(gè)注冊(cè)接口，有參數(shù)校驗(yàn)、判斷用戶是否已經(jīng)注冊(cè)、插入用戶記錄、發(fā)送注冊(cè)成功通知等功能。如果你把所有所有功能代碼塞到一個(gè)方法里面，程序邏輯就不清晰，主次不夠分明，反例如下:

其實(shí)，以上這塊代碼，主次不夠分明的點(diǎn):參數(shù)校驗(yàn)就占registerUser方法很大一部分。正例可以劃分主次，抽一下小函數(shù)，如下：

public Response registerUser(String userName, String password, String email) {

        //檢查參數(shù)
        checkRegisterParam(userName, password, email);
        //檢查用戶是否已經(jīng)存在
        if (checkUserInfoExist(userName)) {
            Response response = new Response();
            response.setCode(0);
            response.setMsg("注冊(cè)成功");
            return response;
        }

        //插入用戶
        addUser(userName, password, email);
        sendMsgOfRegister(userName, email);

        //構(gòu)造注冊(cè)成功報(bào)文
        Response response = new Response();
        response.setCode(0);
        response.setMsg("注冊(cè)成功");
        return response;
    }

    private void sendMsgOfRegister(String userName, String email) {
        MessageDo messageDo = new MessageDo();
        messageDo.setUserName(userName);
        messageDo.setEmail(email);
        messageDo.setContent("注冊(cè)成功");
        messageService.sendMsg(messageDo);
    }

    private void addUser(String userName, String password, String email) {
        UserInfo addUserInfo = new UserInfo();
        addUserInfo.setUserName(userName);
        addUserInfo.setPassword(password);
        addUserInfo.setEmail(email);
        userService.addUserInfo(addUserInfo);
    }

    private boolean checkUserInfoExist(String userName) {
        UserInfo userInfo = userService.queryUserInfoByUsername();
        if (Objects.nonNull(userInfo)) {
            return true;
        }
        return false;
    }

    private void checkRegisterParam(String userName, String password, String email) {
        if (userName == null || StringUtils.isEmpty(userName)) {
            log.info("用戶名不能為空！");
            throw new BizException();
        }

        if (password == null || password.length() < 6) {
            log.info("密碼長(zhǎng)度不能少于6位！");
            throw new BizException();
        }

        if (email == null || StringUtils.isEmpty(email) || !email.contains("@")) {
            log.info("郵箱格式不正確！");
            throw new BizException();
        } 
    }

13. 安全規(guī)范

代碼評(píng)審，也非常有必要評(píng)審代碼是否存在安全性問(wèn)題。比如：

• 輸入校驗(yàn)：應(yīng)該始終對(duì)任何來(lái)自外部的輸入數(shù)據(jù)進(jìn)行校驗(yàn)，以確保它們符合預(yù)期并且不會(huì)對(duì)系統(tǒng)造成傷害。校驗(yàn)應(yīng)該包括檢查數(shù)據(jù)的類型、大小和格式。
• 防范SQL注入攻擊:在使用SQL查詢時(shí)，應(yīng)該始終使用參數(shù)化查詢或預(yù)處理語(yǔ)句，以防止SQL注入攻擊。
• 防范跨站腳本攻擊（XSS）: 在Web應(yīng)用程序中，應(yīng)該始終對(duì)輸入的HTML、JavaScript和CSS進(jìn)行校驗(yàn)，并轉(zhuǎn)義特殊字符，以防止XSS攻擊。
• 避免敏感信息泄露: 敏感信息（如密碼、密鑰、會(huì)話ID等）應(yīng)該在傳輸和存儲(chǔ)時(shí)進(jìn)行加密，以防止被未經(jīng)授權(quán)的人訪問(wèn)。同時(shí)，應(yīng)該避免在日志、調(diào)試信息或錯(cuò)誤消息中泄露敏感信息。
• 防范跨站請(qǐng)求偽造（CSRF）: 應(yīng)該為所有敏感操作（如更改密碼、刪除數(shù)據(jù)等）添加CSRF令牌，以防止未經(jīng)授權(quán)的人員執(zhí)行這些操作。
• 防范安全漏洞: 應(yīng)該使用安全性高的算法和協(xié)議（如HTTPS、TLS）來(lái)保護(hù)敏感數(shù)據(jù)的傳輸和存儲(chǔ)，并定期對(duì)系統(tǒng)進(jìn)行漏洞掃描和安全性審計(jì)。

其實(shí)我以前寫(xiě)過(guò)一篇文章，保證數(shù)據(jù)安全的10種方案，大家可以看看哈：保證接口數(shù)據(jù)安全的10種方案

14. 事務(wù)控制規(guī)范

• 一般推薦使用編程式事務(wù)，而不是一個(gè)注解 @Transactional的聲明式事務(wù)。因?yàn)?nbsp;@Transactional有很多場(chǎng)景，可能導(dǎo)致事務(wù)不生效。 大家可以看下我的這篇文章哈：美團(tuán)二面:spring事務(wù)不生效的15種場(chǎng)景
• 事務(wù)范圍要明確，數(shù)據(jù)庫(kù)操作必須在事務(wù)作用范圍內(nèi)，如果是非數(shù)據(jù)庫(kù)操作，盡量不要包含在事務(wù)內(nèi)。
• 不要在事務(wù)內(nèi)進(jìn)行遠(yuǎn)程調(diào)用（可能導(dǎo)致數(shù)據(jù)不一致，比如本地成功了，但是遠(yuǎn)程方法失敗了，這時(shí)候需要用分布式事務(wù)解決方案）
• 事務(wù)中避免處理太多數(shù)據(jù)，一些查詢相關(guān)的操作，盡量放到事務(wù)之外（避免大事務(wù)問(wèn)題）

15. 冪等處理規(guī)范

什么是冪等？

計(jì)算機(jī)科學(xué)中，冪等表示一次和多次請(qǐng)求某一個(gè)資源應(yīng)該具有同樣的副作用，或者說(shuō)，多次請(qǐng)求所產(chǎn)生的影響與一次請(qǐng)求執(zhí)行的影響效果相同。

代碼評(píng)審的時(shí)候，要關(guān)注接口是否考慮冪等。比如開(kāi)戶接口，多次請(qǐng)求過(guò)來(lái)的時(shí)候，需要先查一下該客戶是否已經(jīng)開(kāi)過(guò)戶，如果已經(jīng)開(kāi)戶成功，直接返回開(kāi)戶成功的報(bào)文。如果還沒(méi)開(kāi)戶，就先開(kāi)戶，再返回開(kāi)戶成功的報(bào)文。這就是冪等處理。

一般情況有這幾種冪等處理方案：

• select+insert+主鍵/唯一索引沖突
• 直接insert + 主鍵/唯一索引沖突
• 狀態(tài)機(jī)冪等
• 抽取防重表
• token令牌
• 悲觀鎖
• 樂(lè)觀鎖
• 分布式鎖

冪等要求有個(gè)唯一標(biāo)記，比如數(shù)據(jù)庫(kù)防重表的一個(gè)業(yè)務(wù)唯一鍵。同時(shí)強(qiáng)調(diào)多次請(qǐng)求和一次請(qǐng)求所產(chǎn)生影響是一樣的。

大家如果對(duì)接口冪等有興趣的話，可以看下我之前的這篇文章：聊聊冪等設(shè)計(jì)

16. 中間件注意事項(xiàng) （數(shù)據(jù)庫(kù)，redis）

代碼評(píng)審的時(shí)候，如果用數(shù)據(jù)庫(kù)、Redis、RocketMq等的中間件時(shí)，我們需要關(guān)注這些中間件的一些注意事項(xiàng)哈。

比如數(shù)據(jù)庫(kù)：

• 關(guān)注數(shù)據(jù)庫(kù)連接池參數(shù)設(shè)置、超時(shí)參數(shù)設(shè)置是否合理
• 避免循環(huán)調(diào)用數(shù)據(jù)庫(kù)操作
• 如果不分頁(yè)，查詢SQL時(shí)，如果條數(shù)不明確，是否加了limit限制限制
• 數(shù)據(jù)庫(kù)的返回是否判空處理
• 數(shù)據(jù)庫(kù)慢SQL是否有監(jiān)控
• 表結(jié)構(gòu)更新是否做兼容，存量表數(shù)據(jù)是否涉及兼容問(wèn)題考慮
• 索引添加是否合理
• 是否連表過(guò)多等等

比如Redis:

• Redis的key使用是否規(guī)范
• Redis 異常捕獲以及處理邏輯是否合理
• Redis連接池、超時(shí)參數(shù)設(shè)置是否合理
• Redis 是否使用了有坑的那些命令，如hgetall、smember
• 是否可能會(huì)存在緩存穿透、緩存雪奔、緩存擊穿等問(wèn)題。

之前我寫(xiě)過(guò)一篇文章，介紹Redis使用注意點(diǎn)的，大家可以看一下哈:使用Redis，你必須知道的21個(gè)注意要點(diǎn)

17. 注意代碼壞味道問(wèn)題

理解幾個(gè)常見(jiàn)的代碼壞味道，大家代碼評(píng)審的時(shí)候，需要關(guān)注一些哈：

• 大量重復(fù)代碼（抽公用方法，設(shè)計(jì)模式）
• 方法參數(shù)過(guò)多（可封裝成一個(gè)DTO對(duì)象）
• 方法過(guò)長(zhǎng)（抽小函數(shù)）
• 判斷條件太多（優(yōu)化if...else）
• 不處理沒(méi)用的代碼（沒(méi)用的import）
• 避免過(guò)度設(shè)計(jì)

18. 遠(yuǎn)程調(diào)用

遠(yuǎn)程調(diào)用是代碼評(píng)審重點(diǎn)關(guān)注的一欄，比如：

• 不要把超時(shí)當(dāng)作失敗處理: 遠(yuǎn)程調(diào)用可能會(huì)失敗，比如網(wǎng)絡(luò)中斷、超時(shí)等等。開(kāi)發(fā)者需要注意遠(yuǎn)程調(diào)用返回的錯(cuò)誤碼，除非是明確的失敗，如果僅僅是超時(shí)等問(wèn)題，不能當(dāng)作失敗處理！而是應(yīng)該發(fā)起查詢，確認(rèn)是否成功，再做處理。
• 異常處理：遠(yuǎn)程調(diào)用可能會(huì)拋出異常，例如由于服務(wù)端錯(cuò)誤或請(qǐng)求格式不正確等。因此，開(kāi)發(fā)人員需要確保能夠捕獲和處理這些異常，以避免系統(tǒng)崩潰或數(shù)據(jù)丟失。
• 網(wǎng)絡(luò)安全：由于遠(yuǎn)程調(diào)用涉及網(wǎng)絡(luò)通信，因此開(kāi)發(fā)人員需要考慮網(wǎng)絡(luò)安全的問(wèn)題，例如數(shù)據(jù)加密、認(rèn)證、訪問(wèn)控制等。盡可能使用安全的協(xié)議，例如HTTPS 或 SSL/TLS。
• 服務(wù)質(zhì)量：遠(yuǎn)程調(diào)用可能會(huì)影響系統(tǒng)的性能和可用性。因此，開(kāi)發(fā)人員需要確保服務(wù)的質(zhì)量，例如避免過(guò)度使用遠(yuǎn)程調(diào)用、優(yōu)化數(shù)據(jù)傳輸、實(shí)現(xiàn)負(fù)載均衡等。
• 版本兼容：由于遠(yuǎn)程調(diào)用涉及不同的進(jìn)程或計(jì)算機(jī)之間的通信，因此開(kāi)發(fā)人員需要注意服務(wù)端和客戶端之間的版本兼容性。盡可能使用相同的接口和數(shù)據(jù)格式，避免出現(xiàn)不兼容的情況。
• 盡量避免for循環(huán)遠(yuǎn)程調(diào)用: 盡量避免for循環(huán)遠(yuǎn)程調(diào)用，而應(yīng)該考慮實(shí)現(xiàn)了批量功能的接口。