1. 引言

Code Review（下文簡(jiǎn)稱CR），即代碼審查，是一種通過評(píng)審代碼以發(fā)現(xiàn)并修正錯(cuò)誤的實(shí)踐。它不是一個(gè)新概念，但在軟件開發(fā)中，它的重要性毋庸置疑。首先，它可以顯著降低軟件中的缺陷比例；其次，它促進(jìn)了知識(shí)共享，通過評(píng)審的過程，團(tuán)隊(duì)成員可以相互學(xué)習(xí)，增強(qiáng)對(duì)系統(tǒng)的整體理解；最后，CR是一種預(yù)防措施，它有助于維護(hù)代碼的清晰和統(tǒng)一，減輕技術(shù)債務(wù)，提升系統(tǒng)的穩(wěn)定性。

盡管CR有諸多好處，實(shí)際操作中卻面臨不少挑戰(zhàn)。例如，交付壓力可能導(dǎo)致CR被忽視或流于形式；另一方面，缺乏有效技巧和工具支持，可能會(huì)使CR變得低效，甚至引發(fā)團(tuán)隊(duì)內(nèi)的沖突；此外，一些團(tuán)隊(duì)可能會(huì)遇到參與度不足的問題，團(tuán)隊(duì)成員不愿意投入必要的時(shí)間和精力。

在接下來的內(nèi)容中，我們將探討如何克服這些挑戰(zhàn)，優(yōu)化流程，并分享一些實(shí)戰(zhàn)經(jīng)驗(yàn)，以幫助讀者在自己團(tuán)隊(duì)中實(shí)施有效的CR。

?

在此特別感謝JDL平臺(tái)技術(shù)部王鑫、劉建設(shè)、劉風(fēng)、楊宏強(qiáng)、鞠萬奎等對(duì)本文撰寫的幫助。

?

2. Code Review的核心目標(biāo)和基本原則

2.1 核心目標(biāo)

首先，CR并不是走馬觀花，也并不需要面面俱到，我們先要明確以下幾個(gè)核心目標(biāo)。

2.1.1 提高代碼質(zhì)量

CR的首要目標(biāo)是提高代碼質(zhì)量。這包括識(shí)別缺陷、識(shí)別性能問題、確保代碼遵循一致的設(shè)計(jì)原則、提高代碼的可讀性和可維護(hù)性。

2.1.2 風(fēng)險(xiǎn)管理

CR的次要目標(biāo)是發(fā)現(xiàn)潛在風(fēng)險(xiǎn)。通過CR盡早發(fā)現(xiàn)并解決潛在的代碼問題，以降低未來的修復(fù)成本，降低大型項(xiàng)目返工及上線失敗的風(fēng)險(xiǎn)。

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

最后，通過CR促進(jìn)團(tuán)隊(duì)知識(shí)共享。CR過程鼓勵(lì)團(tuán)隊(duì)成員之間的交流和協(xié)作，讓團(tuán)隊(duì)成員相互學(xué)習(xí)對(duì)方的代碼和設(shè)計(jì)思路。這種交流有助于提高團(tuán)隊(duì)的整體技能水平，同時(shí)減少代碼庫(kù)中知識(shí)的單點(diǎn)問題。

?

2.2 基本原則

對(duì)應(yīng)CR的核心目標(biāo)，遵循以下幾個(gè)基本原則有助于做好CR。

2.2.1 專注于代碼質(zhì)量

CR的核心目的是提升代碼質(zhì)量。這包括但不限于代碼的清晰性、可維護(hù)性、性能、安全性和可測(cè)試性等，在評(píng)審過程中應(yīng)時(shí)刻專注于這些方面。

2.2.2 保持一致性的標(biāo)準(zhǔn)

遵循團(tuán)隊(duì)或項(xiàng)目的編碼標(biāo)準(zhǔn)、風(fēng)格指南和最佳實(shí)踐。CR應(yīng)該確保代碼更改都符合這些標(biāo)準(zhǔn)，以便于團(tuán)隊(duì)成員理解和維護(hù)代碼，保持一致性還有助于減少錯(cuò)誤和提高代碼質(zhì)量。

2.2.3 保持尊重/建設(shè)性溝通

溝通是CR過程中的核心元素。所有的反饋都應(yīng)該是建設(shè)性的，目的是改進(jìn)代碼而不是批評(píng)個(gè)人。作為評(píng)審者應(yīng)針對(duì)代碼給出具體、有用的反饋，并在表達(dá)時(shí)考慮代碼作者的感受。

?

3. Code Review的實(shí)踐步驟與技巧

3.1 實(shí)踐步驟

CR的實(shí)踐步驟總體分為三步：準(zhǔn)備、評(píng)審、修改及完成。

3.1.1 準(zhǔn)備

在提交CR之前，應(yīng)該先自行檢查代碼，以確?；镜拇a質(zhì)量且遵循代碼規(guī)范。可以通過單元測(cè)試、靜態(tài)分析插件（例如SonarLint、JD EOS）、借助AI分析插件（例如Copilot、JD JoyCoder）等來完成。

如果更改較大，考慮將其分割成幾個(gè)小的、邏輯上獨(dú)立的commit。這樣不僅能使每次評(píng)審過程更高效，也便于追蹤和管理更改。

提交評(píng)審的時(shí)機(jī)，越早進(jìn)行CR則修改的代價(jià)越小，至少應(yīng)保證在提測(cè)前提交CR及完成修改。

最后，確定適合的評(píng)審者，建議選擇具有業(yè)務(wù)經(jīng)驗(yàn)及較為資深的研發(fā)人員。

3.1.2 執(zhí)行評(píng)審

在評(píng)審過程中，聚焦在代碼質(zhì)量方面（可參考下文提供的checklist）?？刂坪妹看蔚臅r(shí)長(zhǎng)，如果一次評(píng)審時(shí)間過長(zhǎng)，則考慮是否應(yīng)在準(zhǔn)備階段就拆分成多次commit，進(jìn)行多次評(píng)審，而不是在提測(cè)前進(jìn)行一次大型評(píng)審。

3.1.3 修改及完成

開發(fā)者根據(jù)收到的反饋進(jìn)行代碼調(diào)整，改動(dòng)較大時(shí)可能會(huì)進(jìn)行多次反復(fù)評(píng)審，當(dāng)修改完成后，由具有權(quán)限的負(fù)責(zé)人將代碼合并至相應(yīng)分支。

3.2 CR的最佳實(shí)踐技巧

遵循以下的最佳實(shí)踐技巧，有助于解決CR中遇到的各種問題，并保持高效。

3.2.1 有一份明確的checklist

每次評(píng)審時(shí)，評(píng)審者應(yīng)該檢查哪些內(nèi)容？對(duì)照一份明確的checklist，有助于我們專注于代碼質(zhì)量，并保持一致性的標(biāo)準(zhǔn)。以下是一份可供參考的checklist。

?設(shè)計(jì)：主要評(píng)審整體設(shè)計(jì)，例如，API設(shè)計(jì)簡(jiǎn)單清晰，代碼交互、系統(tǒng)交互恰當(dāng)，技術(shù)組件、中間件使用得當(dāng)?shù)取?/p>

?功能性/非功能性：評(píng)審代碼的行為是否符合預(yù)期？大多數(shù)時(shí)候，僅靠評(píng)審并不能發(fā)現(xiàn)每一行代碼是否如期運(yùn)行，我們應(yīng)特別關(guān)注一些異常的極端情況，例如，邊界處理、異常死循環(huán)、非法的輸入輸出、大報(bào)文處理、兼容性問題、線程安全/并發(fā)問題、Exception處理等。

?性能/穩(wěn)定性：對(duì)于一些高吞吐量的系統(tǒng)，響應(yīng)性能尤其重要。例如，確保依賴服務(wù)SLA符合預(yù)期，超時(shí)和重試配置得當(dāng)，避免產(chǎn)生慢SQL、大量鎖等待、線程阻塞/耗盡等。

?可觀測(cè)性：是否在上線后可觀測(cè)代碼運(yùn)行的行為，發(fā)生異常時(shí)可及時(shí)感知？例如，確保方法添加了必要的監(jiān)控埋點(diǎn)、有正確的日志級(jí)別及日志內(nèi)容。

?復(fù)雜度：代碼實(shí)現(xiàn)足夠簡(jiǎn)單嗎？是否有過度設(shè)計(jì)？作為評(píng)審者應(yīng)讓代碼盡量保持簡(jiǎn)潔，以便讓其他的開發(fā)者可以快速理解，降低未來修改時(shí)引入新錯(cuò)誤的風(fēng)險(xiǎn)。

?命名：是否為變量、類、方法等選擇了清晰的名稱？命名應(yīng)遵守代碼規(guī)范，且能夠準(zhǔn)確表達(dá)代碼的意圖，而又不至于過長(zhǎng)難以閱讀。

?注釋：注釋清晰無歧義，應(yīng)解釋代碼“為什么”，而不是“是什么”。注釋更應(yīng)解釋一些代碼外的隱含信息，例如，設(shè)計(jì)的取舍、業(yè)務(wù)背景、某些看起來很tricky的實(shí)現(xiàn)，以及解釋正則表達(dá)式、特定算法等內(nèi)容。

?測(cè)試：是否有適當(dāng)?shù)膯卧獪y(cè)試？需要修改已有的單元測(cè)試？

?風(fēng)格：是否遵循一致的代碼風(fēng)格？風(fēng)格無所謂好壞，但保持一致性的風(fēng)格，會(huì)讓其他團(tuán)隊(duì)成員更容易理解。

?文檔：是否需要更新相關(guān)API說明、Readme等文檔？

3.2.2 避免完美主義

在評(píng)審中發(fā)現(xiàn)問題固然重要，但也應(yīng)結(jié)合實(shí)際約束及現(xiàn)狀進(jìn)行權(quán)衡，并非所有代碼均要達(dá)到理論上的最優(yōu)解及最佳實(shí)踐。只要這次修改讓代碼有所改善，或是向著正確的方向前進(jìn)，那么代碼就是可以接受的。（調(diào)研報(bào)告顯示61%的CR沒有發(fā)現(xiàn)缺陷）

3.2.3 拆分為小型MR/PR/Commit

小型的changelist，擁有降低評(píng)審難度、縮短評(píng)審時(shí)間、減少引入錯(cuò)誤的可能性、易于合并等諸多好處。通常認(rèn)為將changelist控制在只解決一件事（可以只是feature的一部分），視作合適的大小。我們可以按層進(jìn)行水平拆分、按功能進(jìn)行垂直拆分，亦或是結(jié)合兩者，有興趣的讀者可以閱讀文章最后引用的google關(guān)于CR工程實(shí)踐文章。

3.2.4 一次不要評(píng)審過多的代碼

建議將每次評(píng)審的代碼控制在100~300行，最多不超過500行，每次評(píng)審時(shí)間不超過1.5小時(shí)（調(diào)研報(bào)告顯示超過這些閾值會(huì)導(dǎo)致CR質(zhì)量及效率大幅降低）。不過根據(jù)實(shí)際場(chǎng)景不同，讀者可以根據(jù)代碼實(shí)際的復(fù)雜度進(jìn)行調(diào)整。

3.2.5 盡早進(jìn)行小而頻繁的評(píng)審

盡早評(píng)審有助于提前發(fā)現(xiàn)問題，減少后期修正的成本。編碼階段，在IDE環(huán)境安裝靜態(tài)代碼檢查工具，提前預(yù)先檢查代碼風(fēng)格、格式等基本錯(cuò)誤，可減少人工評(píng)審的工作量。面對(duì)大型代碼變更，將代碼分為更小而獨(dú)立的多次commit，盡早進(jìn)行多次評(píng)審，也可提升評(píng)審質(zhì)量，減少返工成本。

3.2.6 保持尊重

保持開放的心態(tài)，拋開自負(fù)，不要將個(gè)人偏好帶入到CR中。作為代碼審查者，應(yīng)意識(shí)到代碼作者更了解其編寫的代碼，并不是每次評(píng)審都需要進(jìn)行代碼調(diào)整?；谑聦?shí)及代碼規(guī)范來提出改進(jìn)建議，會(huì)使代碼作者更容易接受。作為代碼提交者，提交高質(zhì)量的代碼，是對(duì)評(píng)審者和團(tuán)隊(duì)最基本的尊重。保持開放的心態(tài)，將評(píng)審當(dāng)做自我學(xué)習(xí)和提升的過程。

3.2.7 度量和改進(jìn)

設(shè)定一些度量指標(biāo)，并持續(xù)追蹤趨勢(shì)，有助于我們持續(xù)不斷改進(jìn)CR過程。以下是一些可以用作度量的指標(biāo)，例如，審查時(shí)長(zhǎng)、缺陷密度、CR率等。

?

4. 案例分享

以下是身邊真實(shí)發(fā)生的一些CR案例，與3.2.1章節(jié)中的checklist都有相應(yīng)的對(duì)照，供大家參考。為了便于閱讀，部分代碼進(jìn)行了刪除簡(jiǎn)化。

4.1 案例1-異常及并發(fā)情況處理不周

問題：靜態(tài)緩存先clear，再進(jìn)行加載，如果解析過程異常會(huì)導(dǎo)致配置丟失、在高并發(fā)訪問時(shí)讀取到錯(cuò)誤的配置。

改善：應(yīng)使用覆蓋更新的方式。

public class ReverseSwitch {
    private static Map multiConfigAddress = new HashMap();
    
    public void setMultiConfigAddress(String multiConfigAddress){
        ReverseSwitch.multiConfigAddress.clear();
        // 以下是解析字符串配置映射到Map配置中，省略具體過程
        for (/*.....*/) {
            ReverseSwitch.multiConfigAddress.put(/*.....*/);
        }
    }

    public static boolean isMultiConfigSwitch() {
        // .....
    }
}

CR修改后：

public void setMultiConfigAddress(String multiConfigAddress){
    log.info("ReverseSwitch.setMultiConfigAddress {}", multiConfigAddress);
    Map newAddress = new HashMap();
    // 省略解析過程
    for () {
        newAddress.put();
    }
    // 使用覆蓋更新的方式
    ReverseSwitch.multiConfigAddress = newAddress; 
}

4.2 案例2-設(shè)計(jì)問題、可觀測(cè)性不足

問題：1. 本地緩存每小時(shí)失效一次，會(huì)集中產(chǎn)生大量RPC請(qǐng)求加載數(shù)據(jù)（容器數(shù)量*外部請(qǐng)求數(shù)），當(dāng)依賴的RPC服務(wù)抖動(dòng)時(shí)有可能導(dǎo)致雪崩；2. do while語(yǔ)句在遠(yuǎn)程數(shù)據(jù)異常時(shí)，可能循環(huán)次數(shù)超出預(yù)期或產(chǎn)生死循環(huán)，導(dǎo)致tp99超時(shí)、阻塞或OOM；3. 缺少必要的日志及監(jiān)控埋點(diǎn)。

改善：1. 使用redis緩存并預(yù)加載；2. while內(nèi)設(shè)置最大分頁(yè)次數(shù)進(jìn)行break；3. 上層調(diào)用增加監(jiān)控埋點(diǎn)及日志。（由于修改不止一處文件，未一一列出修改后的代碼）

@CacheMethod(key = "vrs.SpareQueryProxyCache.getAllSpareInfo", 
    cacheBean = "localGuavaCacheBean60m", 
    timeout = Constants.REDIS_KEY_TIMEOUT_MINUTES_60)
public List getAllSpareInfo() {
    int pageNum = 0;
    PageDto page;
    List returnList = new LinkedList();
    do {
        page = basicPrimaryWS.getBaseStoreInfoByPage(++pageNum);
        if (page != null && CollectionUtils.isNotEmpty(page.getData())) {
            // 省略對(duì)page內(nèi)容進(jìn)行篩選等邏輯處理代碼
            // ......
            returnList.addAll(page.getData());
        }
    }
    while (page != null && page.getCurPage() < page.getTotalPage());
    return returnList;
}

4.3 案例3-代碼復(fù)雜度

問題：代碼不夠內(nèi)聚，可讀性不好，開發(fā)追加需求時(shí)將多個(gè)校驗(yàn)的邏輯寫到了校驗(yàn)方法外。

改善：將校驗(yàn)邏輯放到對(duì)應(yīng)的校驗(yàn)方法內(nèi)，保持代碼整潔，降低理解難度。

public void buildWaybillCodeList(AfterSaleOrderReceiveContext afterSaleOrderContext) {
    boolean useServiceCode = true;
    // 條件1
    if (condition_1) {
        useServiceCode = false;
    }
    // 其他條件
    if (!canUseServiceCode(afterSaleOrderContext)) {
        useServiceCode = false;
    }
    // 條件2
    if (condition_2) {
        useServiceCode = false;
    }
    List waybillCodeList = new ArrayList();
    if (useServiceCode) {
        // 場(chǎng)景1：?jiǎn)翁?hào)規(guī)則
        waybillCodeList.add(WAYBILLCODE_PREFIX + afterSaleOrderContext.getAfterSaleOrderReceiveDTO().getServiceCode());
    } else {
        // 場(chǎng)景2：?jiǎn)翁?hào)規(guī)則
        waybillCodeList.add(this.preDeliveryId(afterSaleOrderContext));
    }
    // ......
}

private boolean canUseServiceCode(AfterSaleOrderReceiveContext afterSaleOrderContext) {
    List productDetailDTOList = buildMainGiftProductList(afterSaleOrderContext);
    // 只針對(duì)一單一品一個(gè)數(shù)量的返回true
    return productDetailDTOList.size() == 1 && Objects.equals(productDetailDTOList.get(0).getProductCount(), 1);
}

CR修改后：

public void buildWaybillCodeList(AfterSaleOrderReceiveContext afterSaleOrderContext) {
    List waybillCodeList = new ArrayList();
    // 將多次需求變更的邏輯點(diǎn)聚合到職責(zé)明確的方法內(nèi)
    if (canUseServiceCode(afterSaleOrderContext)) {
        // 場(chǎng)景1：?jiǎn)翁?hào)規(guī)則
        waybillCodeList.add(WAYBILLCODE_PREFIX + afterSaleOrderContext.getAfterSaleOrderReceiveDTO().getServiceCode());
    } else {
        // 場(chǎng)景2：?jiǎn)翁?hào)規(guī)則
        waybillCodeList.add(this.preDeliveryId(afterSaleOrderContext));
    }
    // ......
}

private boolean canUseServiceCode(AfterSaleOrderReceiveContext afterSaleOrderContext) {
    // 條件1
    if (condition_1) {
        return false;
    }
    // 條件2
    if (condition_2) {
        return false;
    }
    // 條件3
    List productDetailDTOList = buildMainGiftProductList(afterSaleOrderContext);
    // 只針對(duì)一單一品一個(gè)數(shù)量的返回true
    return productDetailDTOList.size() == 1 && Objects.equals(productDetailDTOList.get(0).getProductCount(), 1);
}

4.4 案例4-增加灰度策略控制

問題：CR過程中發(fā)現(xiàn)無法評(píng)估改動(dòng)影響的業(yè)務(wù)范圍，如有問題可能會(huì)影響100%的流量。

改善：增加灰度策略開關(guān)。

public void setConsigneeAddress(WaybillAddress targetAddress) {
    // 100%修改至新邏輯：A
    // ......
}

CR修改后：

public void setConsigneeAddress(WaybillAddress targetAddress) {
    // 選取可控的特征屬性，例如按流量比例或商家切量
    if (ThreadLocalRandom.current().nextInt(1000) < ducc.getAddressMontageSwitchRate()) {    
        // 新邏輯：A，使用灰度策略，控制本次改動(dòng)影響范圍
        // ......
    } else {
        // 原邏輯：B
        // ......
    }
}

4.5 案例5-善用工具

在提交人工CR前，善用工具進(jìn)行代碼掃描，可能有意想不到的收獲。

對(duì)如下代碼使用JD JoyCoder進(jìn)行自動(dòng)評(píng)審建議。

if (response != null
        && response.getCode() != 0
        && String.valueOf(response.getCode()).length() > 2
        && (KK_PARAM_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2)))
            || KK_BIZ_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2))) {
    throw new BusinessException(StringUtils.isNotBlank(response.getSubMsg()) ? response.getSubMsg() : response.getMsg());
}

JD JoyCoder給出的評(píng)審意見：“代碼中存在一個(gè)潛在的邏輯錯(cuò)誤，這是由于條件判斷中的邏輯運(yùn)算符&&和||的優(yōu)先級(jí)沒有被明確區(qū)分。在Java中，&&操作符的優(yōu)先級(jí)高于||，這意味著在沒有適當(dāng)?shù)睦ㄌ?hào)的情況下，&&綁定的條件會(huì)先被評(píng)估，然后才是||綁定的條件?！?/p>

修改后：

if (response != null
        && response.getCode() != 0
        && String.valueOf(response.getCode()).length() > 2
        && ((KK_PARAM_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2))
        || KK_BIZ_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2)))) {
    throw new BusinessException(StringUtils.isNotBlank(response.getSubMsg()) ? response.getSubMsg() : response.getMsg());
}
// 此段代碼可以進(jìn)一步優(yōu)化，將if里面的條件提前抽取到有明確業(yè)務(wù)語(yǔ)義的變量中，提升可讀性

除目前流行的基于LLM實(shí)現(xiàn)的AI掃描工具外，使用傳統(tǒng)代碼掃描也可以發(fā)現(xiàn)潛在問題。

以下代碼通過靜態(tài)掃描工具發(fā)現(xiàn)問題：直接使用“==”進(jìn)行包裝類型Integer的比較，當(dāng)遇到[-128, 127]范圍外時(shí)比較結(jié)果會(huì)不符合預(yù)期。

if (!(request.getSkuList().stream().allMatch(
        sku -> sku.getPreProduce() != null && 
        sku.getPreProduce() == request.getSkuList().get(0).getPreProduce()
    ))) {
    throw new DOSException(ResultEnum.PRE_PRODUCE_UN_SAME.getCode(), ResultEnum.PRE_PRODUCE_UN_SAME.getMessage());
}

修改后：

if (!(request.getSkuList().stream().allMatch(
        sku -> sku.getPreProduce() != null && 
        sku.getPreProduce().equals(request.getSkuList().get(0).getPreProduce())
    ))) {
    throw new DOSException(ResultEnum.PRE_PRODUCE_UN_SAME.getCode(), ResultEnum.PRE_PRODUCE_UN_SAME.getMessage());
}

?

5. Code Review的成果收益

筆者所在團(tuán)隊(duì)沒有單獨(dú)統(tǒng)計(jì)數(shù)據(jù)來佐證CR與線上缺陷的直接關(guān)聯(lián)。線上質(zhì)量與CR、單元測(cè)試、質(zhì)量測(cè)試、SRE等各方面息息相關(guān)，CR并非銀彈，但是做好CR非常有助于降低缺陷數(shù)量。

通過搜索公開數(shù)據(jù)顯示，行業(yè)中使用CR的項(xiàng)目，潛在缺陷發(fā)現(xiàn)率約在50%~60%之間，大部分的測(cè)試，潛在缺陷發(fā)現(xiàn)率約在30%左右。同時(shí)，數(shù)據(jù)顯示約75%的CR評(píng)審意見影響著軟件的可維護(hù)性/可演化性，這表明CR利于軟件系統(tǒng)的長(zhǎng)期演化。

?

6. 總結(jié)與展望

本文探討了CR的重要性，它可以提前發(fā)現(xiàn)缺陷，有助于知識(shí)共享及團(tuán)隊(duì)能力提升，同時(shí)分享了CR實(shí)踐步驟、技巧、案例等內(nèi)容。當(dāng)然，本文僅是一份參考指南，每個(gè)團(tuán)隊(duì)根據(jù)其所處現(xiàn)狀的不同，可以根據(jù)本文調(diào)整優(yōu)化各自的實(shí)踐流程。

如今，軟件開發(fā)的格局在不斷變化，圍繞CR的實(shí)踐也在不斷發(fā)展。隨著技術(shù)的進(jìn)步，更智能的工具和 AI 輔助平臺(tái)在不斷涌現(xiàn)，這些工具能夠提供更高級(jí)的靜態(tài)分析、模式識(shí)別，甚至預(yù)測(cè)分析，在潛在問題出現(xiàn)之前識(shí)別它們。這種AI上下文感知的能力，將能夠根據(jù)項(xiàng)目特定的編碼風(fēng)格、功能模塊以及依賴關(guān)系，提供針對(duì)性的CR反饋，甚至不再需要人工評(píng)審的介入。

未來，CR將繼續(xù)發(fā)揮其關(guān)鍵作用，我們期待AI+CR成為一個(gè)更加強(qiáng)大和智能的伙伴，使團(tuán)隊(duì)將能夠保持競(jìng)爭(zhēng)力，持續(xù)提升軟件質(zhì)量和交付速度。

?

7. 參考資料

《Google Engineering Practices Documentation》：https://google.github.io/eng-practices/review/?

《Code Review at Cisco Systems》：https://static1.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf?

Wikipeida：https://en.wikipedia.org/wiki/Code_review?

?審核編輯 黃宇