1. 為什么需要 Code Review？

Code Review（代碼評審）是日常開發(fā)中必不可少的步驟，但是一些開發(fā)者重視不夠，沒有體驗到Code Review的好處。覺得自己發(fā)起的Code Review同事沒有認真傾聽，同事發(fā)起的Code Review又在耽誤自己的開發(fā)時間。今天一燈就跟一起總結(jié)一下Code Review的好處。

1.1 統(tǒng)一代碼風格

團隊內(nèi)代碼風格的統(tǒng)一，可以增加代碼的可讀性，便于繼任者快速上手。

你看到下面的換行，是什么感覺？

public class UserService {
    
    @Autowired
    private UserDao userDao;

    /**
     * 不規(guī)范的換行
     */
    public User getUserById(Long userId)
    {
        return userDao.getUserById(userId);
    }
    
}

1.2 提前發(fā)現(xiàn)bug

每個人功能是有限的，不可能考慮的很全面，對業(yè)務的理解也不同。其他人可以站在另一個角度，幫助潛在的bug，規(guī)避線上問題。

1.3 提高代碼質(zhì)量

有些開發(fā)者以完成任務為目的，完全不考慮架構(gòu)風格，老子就是一把梭。接口層直接調(diào)用到數(shù)據(jù)層，代碼調(diào)用混亂，重復編寫。一個方法幾百行，一個類幾千行，寫完第二天自己也看不懂了。

作為程序員還是需要對代碼質(zhì)量有追求的，很多招聘要求面試者有代碼潔癖。雷軍說自己寫的代碼像詩一樣優(yōu)美，咱們普通開發(fā)者也要向大佬看齊。

有些經(jīng)典書籍有助于提升代碼質(zhì)量，像是《重構(gòu)：改善既有代碼的設計》、《代碼整潔之道》、《代碼大全》等。

1.4 促進知識共享

每次做Code Review，都是在做知識分享、交流學習。梳理自己實現(xiàn)方案，學習別人的架構(gòu)風格、業(yè)務思路，對自己的技術(shù)和業(yè)務理解也是一種提高。也有助于培養(yǎng)團隊內(nèi)的技術(shù)氛圍。

1.5 增加業(yè)務學習

了解業(yè)務上增加了什么新功能，對現(xiàn)有業(yè)務的影響是什么，更有助于團隊成員之間溝通與協(xié)作。

2. Code Review 基本原則

在進行 Code Review 時，應遵循以下基本原則，以確保過程的高效和順利：

2.1 以交流學習為目的

幫助同事做Code Review的目的是互相交流學習，而不是抓住同事的錯誤不放，炫耀自己的技術(shù)有多強。團隊成員之間應該保持開放和積極的態(tài)度，互相學習和進步。

2.2 保持客觀和專業(yè)

保持客觀和專業(yè)的態(tài)度，評審代碼的質(zhì)量和符合規(guī)范的程度，而不是評價提交者本人。指出任何錯誤的時候，都要在對方可接受的范圍內(nèi)。

2.3 及時反饋結(jié)果

Code Review 應該是一個及時和持續(xù)的過程。審查者應在收到代碼提交后盡快進行審查，以避免延誤項目進度。同時，提交者在收到反饋后應及時進行修改和回應，以確保問題得到及時解決。審查者在確認修改后，應及時批準代碼合并，以保持開發(fā)流程的高效運轉(zhuǎn)。

3. Code Review 時機

發(fā)起 Code Review 的時機，最好是在需求提測前，這樣可以保證Review后做的代碼變更，可以被測試覆蓋到。

有些開發(fā)者喜歡在上線前發(fā)起 Code Review ，這樣是不對的。誰敢給你做 Code Review ，給你提了審核建議，你也沒辦法修改，馬上就要上線了。

4.Code Review 注意事項

在進行 Code Review 時候，審核者往往不知道從哪下手。可以關(guān)注以下幾個方面，以提高審查的效果和質(zhì)量。

4.1 關(guān)注代碼風格

團隊內(nèi)部最好遵守相同的代碼規(guī)范，比如：變量命名、常量定義、枚舉值定義、代碼格式、日期格式化工具、異常處理、注釋規(guī)范、傳參和響應數(shù)據(jù)包裝、建表規(guī)約等，參考《阿里Java開發(fā)手冊》。

4.2 單元測試要求

單元測試是開發(fā)者最容易忽略的問題，通常要求新增代碼的單測覆蓋率至少達到70%。寫好單元測試用例可以幫助開發(fā)者提高代碼質(zhì)量，減少低級bug，減少調(diào)試時間。

4.3 符合架構(gòu)規(guī)范

代碼是否符合常見的架構(gòu)規(guī)范，比如：單一職責原則、開閉原則、是否存在跨層調(diào)用、是否有重復邏輯、領(lǐng)域邊界劃分是否合理等。

4.4 代碼健壯性

通常只有20%的代碼用來實現(xiàn)核心邏輯，而80%的代碼用來保證程序安全。

實現(xiàn)了核心邏輯之后，代碼的健壯性也是一個不可忽略的指標。可以關(guān)注以下幾個方面：

1. 是否有判空和異常傳參校驗
2. 邏輯邊界是否完整
3. 是否存在線程安全問題
4. 是否存在并發(fā)調(diào)用問題
5. 是否需要支持冪等
6. 是否存在內(nèi)存泄露風險
7. 是否有資源邊界限制
8. 是否存在數(shù)據(jù)一致性問題
9. 是否需要增加限流、熔斷、降級等保護機制
10. 是否需要兼容舊邏輯、舊版本

4.5 接口性能問題

接口性能也是需要重點關(guān)注的問題，可以關(guān)注以下幾個方面：

1. 是否存在循環(huán)調(diào)用（接口、數(shù)據(jù)庫），能否改成批量處理
2. 調(diào)用外部接口是否設置合理的超時時間
3. 對外開放的接口，是否預估調(diào)用量？是否有保護機制（限流、熔斷、降級）？
4. 是否需要增加本地緩存、分布式緩存、多線程、消息隊列
5. 打印日志是否過多

4.6 數(shù)據(jù)安全問題

表現(xiàn)形式為：用戶可以訪問或者操作不屬于自己管理范圍內(nèi)的接口或者接口的數(shù)據(jù)。

需要關(guān)注接口是否需要登錄態(tài)、參數(shù)簽名的校驗，是否有橫向越權(quán)和縱向越權(quán)的問題，對外暴露的數(shù)據(jù)需要脫敏處理。