Code Review 指南

PPT: https://www.yuque.com/itguang/mweb/code-review-zhi-nan

文章目錄

• ​​Code Review 指南​​

• ​​前言​​
• ​​CR 是什麼？​​
• ​​為什麼要做 Code Review ？​​
• ​​CR 的标準​​

• ​​進行 CR 的一些原則​​

• ​​CR 中需要關注什麼？​​

• ​​關注代碼規範​​
• ​​代碼壞味道​​

• ​​Duplicated Code （重複代碼）​​
• ​​Long Method (長函數)​​
• ​​Large Class (過大的類)​​
• ​​Long Parameter List (過長參數列)​​

• ​​降低圈複雜度​​
• ​​關注性能問題​​
• ​​關注分布式事務​​
• ​​關注架構設計。​​
• ​​語境​​
• ​​不要吝啬你的贊賞和鼓勵​​

• ​​如何編寫 CR 評論(Comments)​​

• ​​**禮貌**​​
• ​​解釋為什麼​​
• ​​給予指導​​

• ​​如何處理 CR 評論（Comments）​​

• ​​誰是對的？​​
• ​​惹惱開發者​​
• ​​稍後清理​​
• ​​關于嚴格性 CR 的一般投訴​​

• ​​代碼審查的速度​​

• ​​為什麼代碼審查要快？​​
• ​​代碼審查應該多快？​​
• ​​速度與中斷​​

• ​​Git Commit Message 應該怎樣寫​​
• ​​總結​​

前言

先來看一個令無數開發者聞風喪膽的項目“死亡”三角：

業務壓力引發代碼品質下降，代碼品質下降引發開發效率下降，開發效率下降又加重了業務壓力，最終導緻業務壓力山大，乃至項目爛尾。

如何破解？方法有很多，像精簡業務需求、增加開發人手、更新技術架構等，很多時候需要多管齊下，但凡打掉這個“死亡”三角中的任何一角，就能終止這個惡性循環，甚至逆轉為良性循環。

代碼評審（Code Revew，簡稱CR）的首要打擊目标顯然是“爛代碼”。避免“爛代碼”的最好時機是寫代碼的時候，其次是代碼評審的時候。

CR 是什麼？

來看下 ​​Google Code Review Developer Guide​​ 對其的定義：

“A code review is a process where someone other than the author(s) of a piece of code examines that code.”

Code Review 是一段代碼作者以外的其他人審查該代碼的過程。

在 Google，工程師們使用 CR 來維護代碼和産品的品質。代碼審查的主要目的是確定代碼庫的整體代碼健康狀況随着時間的推移而改善。代碼審查的所有工具和過程都是為此目的而設計的。

還記得初次接觸 Code Review ，那時剛從學校畢業，程式設計都是自學，走的都是野路子。畢業後入職，公司老闆和leader都是外企出來的，工程師文化比較濃厚，其中 CR 也是必不可少。入職沒多久就送出了自己的第一個需求，第二天一來，打開 Gitlab 的 Merge Request，收到了 34 個 Comments，平均每個類 5 個 Comments，可想而知，當時我的内心是有多崩潰，但是仔細看每個 Comments 提的建議都非常中肯，有些甚至是 BUG 級别的 Comments。後來我痛定思痛，把别人對我的所有的 Comments 都整理記錄了下來，分類總結，吸取教訓，過了幾個月之後，我的 Comments 數量顯著減少，也真正體會到了 CR 機制帶給我的變化和好處。初次接觸 CR 的人，肯定剛開始是不适應的，但是當了解了 CR 的好處後，你會非常享受這種機制。

一張圖先來看看 CR 在開發流程中的位置:

CR 整體流程:

下面 8 條有關 CR 的闡述，你覺得哪些是正确的？

1. 搞形式主義，存粹是浪費時間
2. CR 是保證程式正确性的手段
3. CR 是保證代碼規範的手段
4. CR 是 Leader 的事，跟我沒關系
5. 我隻看指給我的 CR，其他 CR 跟我沒關系
6. 沒有時間 CR，直接 Merge
7. CR 必須一行不落從頭看到尾
8. CR 必須一次完成

請仔細思考 60 秒

3…2…1…時間到，你的答案是幾條？很抱歉，在我看來，沒有一條是正确的。

1、4、5、6 是送分題，顯然都是錯誤的。

7 是眉毛胡子一把抓，CR 就像讀書，不是所有的書都适合精度，也不是所有的代碼都需要評審。

8 是任務心态，為了 CR 而 CR，CR 的目的不是完成 CR，而在于提升代碼品質，你寫代碼時也不會一次完成所有功能。

比較有争議的是 2 和 3，誠然，正确性和代碼規範都是 CR 要關注的方面，但這并不意味着 CR 要保證正确性和代碼規範（CR 也沒法保證），保證正确性的主要手段是測試（單元測試，內建測試，契約測試，功能測試，自動化測試等），而保證代碼規範主要依靠代碼規範檢查工具（像常用的 checkstyle 和 PMD）。

為什麼要做 Code Review ？

IBM 的 Orbit 項目有 50 萬行代碼，使用了 11 級的代碼檢查（其中包含代碼評審），結果是項目提前傳遞，并且隻有通常預期錯誤的 1%。一份對 AT＆T 的一個 200 多人組織的研究報告顯示，在引入代碼評審後，生産率提高了 14％，缺陷減少了 90％。

《左耳聽風》作者陳皓對代碼品質的評級有過這樣的描述：

我個人認為代碼有這幾種級别：1）可編譯，2）可運作，3）可測試，4）可讀，5）可維護，6）可重用。通過自動化測試的代碼隻能達到第3）級，而通過CODE REVIEW的代碼少會在第4）級甚至更高。

我認為，Code Review 可以為我們帶來三大好處。代碼品質提升，知識交流，學習。

程式設計是一種技巧，是可以通過訓練提高的。

那到底什麼是代碼評審？如何進行代碼評審？業界有很多 CodeReview 規範，本文我們介紹 Google 的 CodeReview 是如何做的？

CR 的标準

一個 CL​​1​​

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.

通常，一旦CL處于能改善所處理系統的整體代碼健康狀況的狀态，即使CL并不完美，Reviewers 也應該傾向于準許它。

當然，這是有局限性的。例如，如果 CL 在其系統中添加了 Reviewers （審閱者）不想要的功能，那麼即使代碼設計良好，Reviewers 也可以拒絕準許。

這裡的一個關鍵點是 沒有“完美”的代碼——隻有更好的代碼 。Reviewers 不應要求作者在準許之前對 CL 的每一小塊進行潤色。相反，Reviewers 應該平衡項目的進展與他們建議之間的重要性。Reviewers 不應該追求完美，而應該追求的是 持續改進。一個整體上提高了系統的可維護性、可讀性和可了解性的 CL 不應該因為它不是“完美的”而延遲數天或數周。

進行 CR 的一些原則

代碼審查的重要功能是向開發人員傳授有關語言、架構或一般軟體設計原則的最佳途徑。留下有助于開發人員學習新知識的評論總是好的。下面是 google 提到的一些指導原則:

• 技術事實和資料大于 觀點和個人偏好。
• 在風格問題上，風格指南（Style Guide）​​2​​
• 軟體設計的各個方面幾乎從來都不是純粹的風格問題或隻是個人喜好。它們基于基本原則（SOLID），應根據這些原則進行權衡，而不僅僅是個人意見。有時有幾個有效的選項。如果作者可以證明（通過資料或基于可靠的工程原理）幾種方法同樣有效，那麼 Reviewers 應該接受作者的偏好。否則，選擇由軟體設計的标準原則決定。
• 如果沒有其他規則适用，那麼 Reviewers 可能會要求作者與目前代碼庫中的内容保持一緻，隻要這不會惡化系統的整體代碼健康。
• 在代碼審查的任何沖突中，第一步應該始終是讓開發人員和 Reviewers 根據CR 規範 和 風格指南 等文檔的内容來嘗試達成共識 。當達成共識變得特别困難時，在 Reviewers 和作者之間召開面對面會議或視訊會議會有所幫助，而不僅僅是試圖通過代碼審查評論來解決沖突。如果這不能解決問題，最常見的解決方法是更新。更新路徑通常是進行更廣泛的團隊讨論，讓技術主管參與進來，提供幫助。不要因為作者和 Reviewers 無法達成協定而讓 CL 坐視不管。

CR 中需要關注什麼？

代碼審查是提高代碼品質、建立最佳實踐和傳播知識的強大工具。但是，當你嘗試在團隊中實施有效的代碼審查流程時，會遇到許多挑戰。

此外，代碼審查如果做錯了，可能會一事無成，甚至會損害你的人際關系。是以，重要的是要注意代碼審查的人為方面。Submitter 和 Reviewers 都需要一個指南針來進行建設性和尊重的代碼審查。

下面列舉 CR 時需重點關注的幾個方面，并輔以相應的例子便于了解。

關注代碼規範

• 代碼風格：

  如果現有代碼與樣式指南不一緻怎麼辦？根據我們的 代碼審查原則，樣式指南是絕對權威：如果樣式指南有要求，CL 應該遵循指南。常見的風格不一緻問題包括：空白字元、換行、大小寫，注釋等問題。

• 命名：

  衆所周知，程式設計中，命名被視為第一大難題。開發人員是否為代碼選擇了好名字？一個好的名稱可以充分傳達該項目是什麼或做什麼，而不會太長以至于難以閱讀。一個令人費解的命名背後往往隐藏着一個設計纰漏。

• 注釋：

  開發者有沒有用通俗易懂的注釋寫清楚代碼的用途？所寫的注釋真的有必要嗎？如果代碼不夠清晰，無法自我解釋，便會有大段注釋來說明。那麼此時代碼應該更簡單。良好的代碼應該是不言而喻的。

代碼壞味道

Duplicated Code （重複代碼）

程式設計法則第一條，Don’t repeat yourself. 重複代碼是萬惡之首，重複代碼人人得而誅之！

重複代碼就是不同地點，有着相同的程式結構。一般是因為需求疊代比較快，開發小夥伴擔心影響已有功能，就複制粘貼造成的。重複代碼很難維護的，如果你要修改其中一段的代碼邏輯，就需要修改多次，很可能出現遺漏的情況。

如何優化重複代碼呢？分三種情況讨論：

1. 同一個類的兩個函數含有相同的表達式

class A {
    public void method1() {
        doSomething1
        doSomething2
        doSomething3
    }
    public void method2() {
        doSomething1
        doSomething2
        doSomething4
    }
}      

優化手段：可以使用 ​

​Extract Method(提取公共函數)​

​ 抽出重複的代碼邏輯，組成一個公用的方法。如下：

class A {
    public void method1() {
        commonMethod();
        doSomething3
    }
    public void method2() {
        commonMethod();
        doSomething4
    }
    
    public void commonMethod(){
       doSomething1
       doSomething2
    }
}      

1. 兩個互為兄弟的子類内含相同的表達式

class A extend C {
    public void method1() {
        doSomething1
        doSomething2
        doSomething3
    }
}

class B extend C {
    public void method1() {
        doSomething1
        doSomething2
        doSomething4
    }
}      

優化手段：對兩個類都使用Extract Method(提取公共函數)，然後把抽取出來的函數放到父類中。

class C {
    public void commonMethod(){
     doSomething1
     doSomething2
   }
}
class A extend C {
    public void method1() {
        commonMethod();
        doSomething3
    }
}

class B extend C {
    public void method1() {
        commonMethod();
        doSomething4
    }
}      

1. 兩個毫不相關的類出現重複代碼

如果是兩個毫不相關的類出現重複代碼，可以使用Extract Class将重複代碼提煉到一個類中。這個新類可以是一個普通類，也可以是一個工具類，看具體業務怎麼劃分吧。

Long Method (長函數)

長函數是指一個函數方法幾百行甚至上千行，可讀性大大降低，不便于了解。反例如下：

public class Test {
    private String name;
    private Vector<Order> orders = new Vector<Order>();

    public void printOwing() {
        //print banner
        System.out.println("****************");
        System.out.println("*****customer Owes *****");
        System.out.println("****************");

        //calculate totalAmount
        Enumeration env = orders.elements();
        double totalAmount = 0.0;
        while (env.hasMoreElements()) {
            Order order = (Order) env.nextElement();
            totalAmount += order.getAmout();
        }

        //print details
        System.out.println("name:" + name);
        System.out.println("amount:" + totalAmount);
        ......
    }
}      

可以使用Extract Method，抽取功能單一的代碼段，組成命名清晰的小函數，去解決長函數問題，正例如下:

public class Test {
    private String name;
    private Vector<Order> orders = new Vector<Order>();

    public void printOwing() {

        //print banner
        printBanner();
        //calculate totalAmount
        double totalAmount = getTotalAmount();
        //print details
        printDetail(totalAmount);
    }

    void printBanner(){
        System.out.println("****************");
        System.out.println("*****customer Owes *****");
        System.out.println("****************");
    }

    double getTotalAmount(){
        Enumeration env = orders.elements();
        double totalAmount = 0.0;
        while (env.hasMoreElements()) {
            Order order = (Order) env.nextElement();
            totalAmount += order.getAmout();
        }
        return totalAmount;
    }

    void printDetail(double totalAmount){
        System.out.println("name:" + name);
        System.out.println("amount:" + totalAmount);
    }
    
}      

Large Class (過大的類)

一個類做太多事情，維護了太多功能，可讀性變差，性能也會下降。Duplicated Code 也就接踵而至了。

Class A{
  public void printOrder(){
   System.out.println("訂單");
  }
  
  public void printGoods(){
   System.out.println("商品");
  }
  
  public void printPoints(){
   System.out.println("積分");
  }
}      

解決方法： 按照 單一職責 原則，使用 Extract Class 把代碼劃分開。

Class Order{
  public void printOrder(){
   System.out.println("訂單");
  }
}

Class Goods{
   public void printGoods(){
   System.out.println("商品");
  }
}
 
Class Points{   
  public void printPoints(){
   System.out.println("積分");
  }
 }
}      

Long Parameter List (過長參數列)

方法參數數量過多的話，可讀性很差。如果有多個重載方法，參數很多的話，有時候你都不知道調哪個呢。并且，如果參數很多，做新老接口相容處理也比較麻煩。

public void getUserInfo（String name,String age,String sex,String mobile){
  // do something ...
}      

如何解決過長參數列問題呢？将參數封裝成結構或者類，比如我們将參數封裝成一個DTO類，如下：

public void getUserInfo（UserInfoParamDTO userInfoParamDTO){
  // do something ...
}

class UserInfoParamDTO{
  private String name;
  private String age; 
  private String sex;
  private String mobile;
}      

更多代碼壞味道可閱讀 《重構》這本書。

降低圈複雜度

什麼是圈複雜度？簡單來說就是代碼中 if/case/for/while 出現的次數。圈複雜度越高，BUG 率越高。如果一個方法的圈複雜度達到 5 或者更高，那麼 CR 時就要多看兩眼。太複雜通常意味着“無法被開發者快速了解”。這也可能意味着“開發人員在嘗試調用或修改此代碼時可能會引入錯誤”。

public static void testCase(Integer num){
        switch (num){
            case 1:
                System.out.println(num);
                break;
            case 2:
                System.out.println(num);
            case 3:
                System.out.println(num);
        }
    }      

public Integer testCase(String numStr) {
        Integer num = null;
        if (StringUtils.isEmpty(numStr)) {
            return 0;
        } else {
            num = Integer.valueOf(numStr);
        }
        return num;
    }      

優化後

public Integer testCase(String numStr) {
        if (StringUtils.isEmpty(numStr)) {
            return 0;
        }
        return Integer.valueOf(numStr);

    }      

public void test() {
    if(條件1成立){
        if(條件2成立){
            執行xxx邏輯;
        }
    }
}      

public void test() {
    if(!條件1成立){
        return;
    }
    if(!條件2成立){
        return;
    }
    執行xxx邏輯;
}      

關注性能問題

性能問題雖然不常見，可一旦暴雷往往就是大問題。下面是一些 CR 時通常需要關注的點。

不要在循環中操作資料庫或者調用遠端服務。

如果可以的話，使用數組實作的集合類型時預估大小。

不要在循環中使用 try…catch…，應該把其放在最外層。

變量不要重複計算。

循環内不要不斷建立對象引用。

異常隻能用于錯誤處理，不應該用來控制程式流程。

字元串拼接 盡量使用 StringBuilder/StringJoiner。

…

下面舉兩個例子：

變量的重複計算。

for (int i = 0; i < list.size(); i++) {...}

優化後

for (int i = 0, length = list.size(); i < length; i++) {...}      

循環内不要不斷建立對象引用。

for (int i = 1; i <= count; i++){
    Object obj = new Object();
}

優化後

Object obj = null;
for (int i = 0; i <= count; i++) {
    obj = new Object();
}      

關注分布式事務

涉及遠端服務調用，或者跨庫更新的場景，都應考慮是否存在分布式事務問題，以及适用何種處理方式，是依賴架構保證強一緻性，還是記錄異常資料保證最終一緻性，抑或是直接忽略？

關注架構設計。

代碼有代碼規範，架構有架構規範。面對一個新功能的 CL，除了檢查架構規範，還應推敲其架構設計，比如是否符合整潔架構三原則，無依賴環原則，穩定依賴原則，穩定抽象原則。

如果閱讀代碼有些困難，減 CR 的速度，應該找到對應的作者，讓其解釋溝通清楚，然後再嘗試審查它。如果你看不懂代碼，其他開發人員很可能也不會。是以，當你要求開發人員對其進行解釋時，你也在幫助未來的開發人員了解此代碼。

語境

通常，代碼審查工具隻會顯示正在更改的部分周圍的幾行代碼。有時必須檢視整個檔案以確定更改确實有意義。例如，你可能會看到隻添加了四個新行，但是當你檢視整個檔案時，你會發現這四行位于一個 50 行的方法中，需要将其分解為更小的方法。

不要吝啬你的贊賞和鼓勵

如果你在 CL 中看到了不錯的内容，請告訴開發人員，尤其是當他們以出色的方式處理你的 Comments時。Reviewers 通常隻關注錯誤，但他們也應該為良好實踐提供鼓勵和贊賞。有時，在指導方面，告訴開發人員他們做對了什麼比告訴他們做錯了什麼更有價值。

如何編寫 CR 評論(Comments)

上面我們介紹了 CR 時需要的關注點，那麼如果發現有問題，需要提 Comments 時，我們該注意些什麼呢？

禮貌

一般來說，禮貌和尊重是很重要的，彬彬有禮的人總是受人喜歡。做到這一點的一種方法是確定你總是對代碼發表評論，而不是對開發人員發表評論。

壞： “在對并發性顯然沒有好處的情況下，為什麼要使用線程”。

好： “這裡的并發模型增加了系統的複雜性，而我看不到任何實際的性能優勢。因為沒有性能優勢，是以最好讓這段代碼是單線程的，而不是使用多線程。”

解釋為什麼

從上面的例子中可以看出，Reviewers 應該盡量讓開發者明白為何會有這一次 Comments ，Reviewers 并不總是需要在 Comments 中包含這些資訊，但有時對 Comments 的意圖、遵循的最佳實踐或建議進行更多解釋是很有必要的。

給予指導

一般來說，解決 Comments 是開發人員的責任，而不是 Reviewers 的責任。你不需要為開發人員進行解決方案的詳細設計或編寫代碼。

不過，這并不意味着 Reviewers 不需要進行幫助。一般來說，Reviewers 應該在指出問題和提供直接指導之間取得适當的平衡。指出問題并讓開發人員做出決定通常有助于開發人員學習，并使代碼審查變得更容易。它還可以産生更好的解決方案，因為開發人員比審閱者更接近代碼。

如何處理 CR 評論（Comments）

有時開發人員會推遲代碼審查。他們要麼不同意 Reviewers 的建議，要麼抱怨 Reviewers 總體上過于嚴格。

誰是對的？

當開發人員不同意你的建議時，請先花點時間考慮一下它們是否正确。通常，開發人員比你更接近代碼，是以他們可能對代碼的某些方面有更好的了解。如果是這樣，讓他們知道他們是對的，讓問題消失。

但是，開發人員并不總是正确的。在這種情況下，你應該耐心禮貌的對開發人員進行解釋。一個好的解釋表明了對開發人員回複的了解。

特别是，當你認為解決 Comments 帶來的代碼品質改進證明所要求的額外工作是合理的，他們應該繼續堅持。 改善代碼健康往往是在小步驟中發生的。

惹惱開發者

Reviewers 有時認為，如果自己堅持要求改進，開發人員會感到不安。有時開發人員确實會感到沮喪，但這通常是短暫的，他們稍後會非常感謝你幫助他們提高代碼品質。通常，如果你的評論有禮貌，開發人員實際上根本不會生氣。不安通常是因為 Comments 的編寫方式，而不是 Reviewers 對代碼品質的堅持。

稍後清理

一個常見的回擊來源是開發人員想要完成任務。他們不想為了解決這個 Comments 而進行額外工作。是以他們說他們會在以後的 CL 中清理一些東西。

然而，經驗表明，随着開發人員編寫原始 CL 後的時間越長，這種清理工作發生的可能性就越小。事實上，通常除非開發人員立即進行解決現在的 Comments ，否則它永遠不會發生。這并不是因為開發人員不負責任，而是因為他們有很多工作要做，而清理工作會在其他工作的壓力下丢失或被遺忘。是以，通常最好堅持讓開發人員現在解決他們的 Comments。讓開發者“稍後清理”是代碼庫退化的常見方式。

如果 Comments 引入了新的複雜性，除非是緊急情況，否則必須在送出之前對其進行清理。如果 Comments 現在無法解決，開發人員應該送出一個 bug 并将其配置設定給自己，這樣它就不會丢失。

關于嚴格性 CR 的一般投訴

如果你之前的 CR 相當松懈，而你轉而進行嚴格的審查，那麼一些開發人員會非常大聲地抱怨。提高 CR 的速度通常會導緻這些抱怨消失。

有時這些抱怨可能需要幾個月的時間才能消失，但最終開發人員往往會看到嚴格 CR 的價值，因為他們看到了他們幫助編寫了哪些出色的代碼。有時，最響亮的抗議者甚至會成為你最堅定的支援者，讓他們真正看到你通過嚴格 CR 增加的價值。

代碼審查的速度

上面在 關于嚴格性 CR 的一般投訴 一節中我們提到，提高 CR 的速度有助于減少 開發人員的抱怨，但是對于 Reviewers 來說，本身可能也是一個開發者，手裡有很多工作在做。這個 CR 的速度如何保證呢？

為什麼代碼審查要快？

首先，我們要明确的是：我們的目标是優化開發人員團隊共同生産産品的速度，而不僅僅是優化單個開發人員編寫代碼的速度。個人發展的速度固然是是非常重要的，它隻是不作為整個團隊的速度很重要。

有時 Reviewers 為了速度直接通過開發者的 CL，看似提高了效率，但是未經嚴格審查的代碼可能會隐藏巨大的不确定性，影響以後的閱讀和擴充性，得不償失。

當代碼審查緩慢時，會發生幾件事：

• 整個團隊的速度降低了：沒有快速 CR 和 及時解決 Comments 會導緻團隊其他成員的新功能和錯誤修複會出現延遲。
• 開發人員開始抗議代碼審查過程：如果 Reviewers 每隔幾天才回複一次，但每次都要求對 CL 進行重大更改，這對開發人員來說可能會令人沮喪和困難。
• 代碼運作狀況可能會受到影響：當 CR 緩慢時，開發人員的壓力就會增加。緩慢的 CR 也阻礙了代碼清理、重構和對現有 CL 的進一步改進。

代碼審查應該多快？

收到 CL 之後，先判斷一下 CL 的性質，如果是 Bug Fix 類型的 CL，應盡快評審，如果是新功能 CL，則可以等待下一個 CR 視窗。

一個工作日是響應 CR 請求（即第二天早上的第一件事）應該花費的最長時間。

遵循這些準則意味着典型的 CL 應該在一天内獲得多輪審查。

速度與中斷

如果你正忙于一項重點任務，例如編寫代碼，請不要打擾自己進行 CR 。 研究表明，開發人員在被中斷後可能需要很長時間才能恢複平穩的開發流程。是以，在編碼時打斷自己對團隊來說實際上 比讓另一個開發人員等待 CR 更昂貴。

相反，在你回複 CR 請求之前，請等待你的工作出現斷點。這可能是你目前的編碼任務完成時、午餐後、從會議回來、從休息室回來等。

Git Commit Message 應該怎樣寫

Git Commit Message 在 CR 時的作用也很重要，一個好的 Git Commit Message 應該能夠清晰點明主題，是 bug 還是 feature 還是 doc 的完善，應該讓 Reviewers 一目了然。

我們在日常使用Git送出代碼時經常會寫 commint message，否則就不允許送出。一般來說，commit message 應該清晰明了，說明本次送出的目的。目前，社群有多種 Commit message 的寫法規範。推薦使用 Angular 規範，這是目前使用最廣的寫法，比較合理和系統化，并且有配套的工具。

可以參考IDEA 中 Git Commit message 編寫 來學習 IDEA 中如何友善的編寫 Commit Message

總結

• ​​Google Engineering Practices Documentation​​
• ​​代碼評審賦魅​​
• ​​陳皓：CODE REVIEW中的幾個提示​​
• ​​Code Review Guidelines for Humans​​

1. CL：代表“ChangeList”，意思是已經送出給版本控制或正在進行代碼審查的一個獨立的更改。其他組織通常将此稱為“更改”、“更新檔”或“拉取請求”，如果你使用 GitLab， CL 就是你的 Merge Request 簡稱 MR，如果你使用 GitHub ，CL就是你的 Push Request 簡稱 PR。​​↩︎​​
2. 風格指南（Style Guide）：每個主要的開源項目都有自己的風格指南：一組關于如何為該項目編寫代碼的約定（有時是任意的）。當其中的所有代碼都采用一緻的樣式時，了解大型代碼庫會容易得多。一個公司也應該有自己的風格指南，國内一般都愛參考 《阿裡巴巴編碼規約》。最好結合一些靜态代碼檢查工具如 Checkstyle，PMD 等制定出符合本公司本團隊的風格指南。重點是自己的團隊要都認同并遵守。​​↩︎​​