1. 為什么需要 Code Review？

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

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

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

你看到下面的換行，是什么感覺(jué)？

public class UserService {
    
    @Autowired
    private UserDao userDao;

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

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

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

1.3 提高代碼質(zhì)量

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

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

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

1.4 促進(jìn)知識(shí)共享

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

1.5 增加業(yè)務(wù)學(xué)習(xí)

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

2. Code Review 基本原則

在進(jìn)行 Code Review 時(shí)，應(yīng)遵循以下基本原則，以確保過(guò)程的高效和順利：

2.1 以交流學(xué)習(xí)為目的

幫助同事做Code Review的目的是互相交流學(xué)習(xí)，而不是抓住同事的錯(cuò)誤不放，炫耀自己的技術(shù)有多強(qiáng)。團(tuán)隊(duì)成員之間應(yīng)該保持開(kāi)放和積極的態(tài)度，互相學(xué)習(xí)和進(jìn)步。

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

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

2.3 及時(shí)反饋結(jié)果

Code Review 應(yīng)該是一個(gè)及時(shí)和持續(xù)的過(guò)程。審查者應(yīng)在收到代碼提交后盡快進(jìn)行審查，以避免延誤項(xiàng)目進(jìn)度。同時(shí)，提交者在收到反饋后應(yīng)及時(shí)進(jìn)行修改和回應(yīng)，以確保問(wèn)題得到及時(shí)解決。審查者在確認(rèn)修改后，應(yīng)及時(shí)批準(zhǔn)代碼合并，以保持開(kāi)發(fā)流程的高效運(yùn)轉(zhuǎn)。

3. Code Review 時(shí)機(jī)

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

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

4.Code Review 注意事項(xiàng)

在進(jìn)行 Code Review 時(shí)候，審核者往往不知道從哪下手?？梢躁P(guān)注以下幾個(gè)方面，以提高審查的效果和質(zhì)量。

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

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

4.2 單元測(cè)試要求

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

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

代碼是否符合常見(jiàn)的架構(gòu)規(guī)范，比如：?jiǎn)我宦氊?zé)原則、開(kāi)閉原則、是否存在跨層調(diào)用、是否有重復(fù)邏輯、領(lǐng)域邊界劃分是否合理等。

4.4 代碼健壯性

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

實(shí)現(xiàn)了核心邏輯之后，代碼的健壯性也是一個(gè)不可忽略的指標(biāo)?？梢躁P(guān)注以下幾個(gè)方面：

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

4.5 接口性能問(wèn)題

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

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

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

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

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