Code Review：探索工程實踐之道

作者：京東物流 馮志文

前言

本文參考《京東JAVA代碼規範-V1.1》&Google代碼評審工程實踐方法論，結合團隊代碼評審的實踐經驗整理成文檔，這份文檔是我們團隊集體經驗的結晶。我相信公司其他部門也有類似的經驗和最佳實踐。希望通過互相交流和學習，共同提高代碼品質，進而提高系統的穩定性。

名詞解釋：

CL： “changelist”修改清單，它是送出到coding版本控制工具中的一次代碼修改（即将稽核的代碼）

CR：CodeReview代碼評審

一、為什麼需要CR

代碼品質是軟體品質的基石

1.我們進行代碼評審的目的是為了提升代碼品質，盡早發現潛在缺陷與BUG，降低修複成本。同時，這也有助于促進團隊内部的知識共享，幫助更多人更好地了解我們的系統。

2.從系統的角度來看，代碼審查可以幫助我們提前發現問題，減少bug，提高穩定性，避免到處救火的情況發生。

3.從開發人員來看，代碼評審是一個逐漸改正不良習慣的過程，可以提高編碼、設計、架構能力。讓他們從自身犯過的錯誤中學習，并從他人的思路中成長。

4.從評審者來看，這也是一個學習他人編碼能力的機會。我們可以從他們的經驗和技巧中汲取養分，不斷提高自己的專業素養。

5.從團隊管理來看，代碼評審提高團隊凝聚力，熟悉彼此的子產品業務。這将使我們更加團結協作，降低因人員流失帶來的成本和風險。

......

請記住，代碼評審不是批鬥會。我們的目标是針對代碼本身，而不是針對人。我們應該以建設性的方式提出問題和改進意見，以幫助開發人員提高程式設計技能和整體水準。

最後，請確定團隊所有開發者都了解并接受這個流程。如果團隊有人對此産生抵觸或反感，那麼這個目的就無法實作。小組剛開始代碼評審也是這樣，大家總覺得不好意思指出别人的不合理之處。是以，請大家共同努力，讓代碼評審成為我們團隊文化的一部分。

二、CR流程規範

CR前提條件：

1.本地通過IDEA各種插件檢查一般性的錯誤。比如使用JoyCoder、京東編碼規約、Sonar等

2.自測通過，確定基本功能流程沒問題

将CR前置，避免到最後上線的時候合并到Master做CR。履約需求上線CR至少經過2輪，第一次是提測前，最後一輪是上線前。每一輪的側重點不一樣。流程如下：

備注：Dev分支主要作用local代碼庫的遠端備份，這個備份動作是通過不斷commit&push完成，是以不用擔心代碼丢失。Feature分支承擔功能測試和CR的作用，因為有Dev一層屏蔽了中途反複地修改，使得送出地PR更為清晰。Master是上線使用的分支。

第一次CR：

項目提測前（合并到feature分支）

1.為什麼是測試前？

2.如果都測試完成了要上線了，CR的意義在哪裡？CR發現的很多問題還改不改？

3.提測前CR回報的問題細緻全面，研發可以及時修複。

中間CR：

（合并到feature分支）

1.主要是修複測試提的BUG之類，或者這個需求很久了，需要重新拉取最新的線上代碼master

最後一次CR：

上線前（合并master主幹）

1.這時候核心是CR代碼沖突，代碼是否有遺漏，配置是否準确？上線是否有其他風險點？

切記代碼上線前的最後一次CR後，務必需要經過測試回歸驗證，引流驗證等，以防合并代碼遺漏等情況。對上線前代碼再次回歸驗證沒問題後才可以上線

代碼評審 整個過程 分為 評審者和開發中。接下來分别解釋下評審者指南和開發者指南。

三、代碼評審者指南

在進行代碼評審時，我們可以從不同的角度出發，包括評審者和開發者的角度來進行。

首先，從評審者的角度來看，我們需要了解一些評審的指南。這些指南包括：

1.哪些人可以參與代碼稽核？

2.評審方式有哪些？标準是什麼？

3.評審者應該關注哪些？

1、哪些人可以參與代碼稽核呢？

1.小組長TL：從團隊角度出發，需要有全局觀，重點關注【穩定性】【代碼可讀性】等

2.架構師：從系統架構出發，核心關注【代碼思路是否和架構設計一緻】

3.核心骨幹：為了確定代碼品質和項目穩定性，我們通常會選擇團隊中最優秀的代碼稽核者來進行稽核。這個人應該具備足夠的經驗和技能，能夠在你期望的時間内對稽核工作負責。

4.團隊成員：如果長期是核心骨幹CR，這樣會導緻團隊其他人員參與度不高，需鼓勵團隊其他成員參與代碼稽核

前提條件

1.作為評審者，我們需要對項目的需求和設計文檔有充分的了解，以便更好地了解代碼的目的和實作方式。

2.評審者需要對評審的代碼負責，而不是不看直接merge通過之類。

注意事項

1.有時候一個代碼稽核者無法覆寫整個CL，因為其中可能包含太多的代碼檔案或者需要不同的技術背景來了解。在這種情況下，我們需要多位稽核者參與稽核，以確定能夠覆寫所有的代碼檔案。我們應該考慮使用多個稽核者來互相檢查和驗證代碼品質，進而減少潛在的錯誤和漏洞。

2.不建議剛加入團隊成員不足3個月并且還不熟悉業務的新人，具體可根據團隊情況考慮。

2、評審的方式有哪些？

1.線上Coding平台（占比90%）：這種方式優點是京Me自動通知友善快捷，可以節省時間和成本。但是需要注意的是，由于Coding平台缺乏Idea其他内容上下文，前期評審者可能不太習慣，需要慢慢适應。

2.線下評審

1.面對面稽核（占比5%）：适合改動較小，這種方式的優點是有疑問時可以随時提問并得到解答，可以直接了解開發者的思路和意圖，有助于發現更深層次的問題。但是需要注意的是，這種方式需要耗費較多的時間和精力。

2.團隊組會審批（占比5%）：對于大型項目需求或者黃金核心鍊路有風險的需求，除了線上評審外，我們可以線下再次Review把控。線下的核心是把控上線風險點（Joyspace列出相關事項），通過團隊内部的讨論和協作來提高代碼品質。這種方式的優點是可以充分發揮團隊的力量，共同解決潛在問題。但是需要注意的是，由于參與人數較多，可能需要較長的時間來完成評審過程。Promise遇到牽扯較大、核心鍊路風險高的需求會采用線下Review風險事宜。

總之，在選擇代碼稽核方式時，我們應該根據具體情況進行選擇。同時，我們也應該注意及時回報評審結果和建議，以便開發者能夠及時修正問題并提高代碼品質。

3、CR的标準是什麼？

代碼稽核的目的是保證持續改進代碼庫品質。

1.原則上，如果送出的代碼能顯著提高品質，即使不完美也準許。

2.稽核者應分享知識，寫一些有助于學習的評論。

3.涉及設計的問題應基于原則權衡，而非個人喜好。

4.如果沒有規則，讓作者與現有代碼保持一緻，不惡化系統品質。

4、代碼稽核步驟有哪些？

1.全面了解 CL背後（需求、技術改造）。這個 CL 是否有意義？它是否包含好的描述？

2.綜觀整個 CL 中最重要的部分。從整體來看，設計是否合理？

1.找到包含 CL “主體”部分的檔案。通常，如果一個檔案包含大量的邏輯修改，那麼它就是 CL 的主體部分。先審視這些主體部分有助于為其他部分理出上下文。如果 CL 太大，很難找到主體部分的位置，可以征詢開發者的建議，你應該先看哪些部分，并建議他把一個CL拆分多個小CL，小步快跑（功能獨立的可設定為一個小CL。比如web頁面操作的分為一個小CL，定時任務Task相關的是一個小CL，API接口部分是一個小CL）

2.如果發現 CL 中有一些重要的設計缺陷或設計問題，立即給出回報，即使現在還沒來得及稽核其他部分。實際上，稽核其他部分很有可能是浪費時間。隻要這個設計問題足夠大，在重新設計時，其他代碼很有可能會消失或變得無關緊要了。

3.以合适的順序檢查CL的其他部分。在确認 CL 沒有重要設計問題之後，整理出審視檔案的順序，并確定不會遺漏任何檔案。通常，在審視了主要檔案之後，最簡單的方式就是按照代碼稽核工具呈現出來的順序周遊每個檔案。有時候，先閱讀測試代碼更有幫助，因為看了測試代碼之後，你就明白這個 CL 的期望行為是什麼。

5、代碼稽核者應該關注哪些？

確定稽核了每行代碼，并且檢視上下文，確定你正在提升代碼品質，當開發者的 CL 中包含 好東西 時，稱贊他們。

5.1、相容性

稽核者需要判斷，本次CL是否會影響線上現有功能

1.比如JSF接口出參的位置，是否會導緻上遊調用序列化出錯？

2.中間件配置變更，比如資料表增加索引，表資料量多大，會不會增加索引導緻資料庫阻塞?

3.是否需要增加Ducc開關技術，在穩定性和代碼複雜性中均衡考量

5.2、設計

1.稽核一個 CL 最重要的事情就是考慮它的整體設計，代碼是否按照架構設計方案進行編碼？

2.API & DataBase 是否合理

3.這段代碼應該放到哪裡更合适？它是否可以很好地與系統其他部分內建？

4.還應關注：技術棧簡單、統一的控制，避免非必要引入三方架構、元件等，為系統穩定性埋下隐患

5.3、功能

1.這個 CL 所實作的功能與需求期望開發的功能是一緻的嗎？

2.絕大多數情況，我們期望開發者在送出 CL 進行稽核之前，已經做過充分的測試。但作為稽核者，在稽核代碼時仍要考慮邊界情況、并發問題等等。確定消滅那些通過閱讀代碼就能發現的缺陷。

3.作為稽核者，你可以根據需要親自驗證 CL 的功能。僅通過閱讀代碼，你很難了解有哪些改變，對系統有哪些影響。對于這種修改，可以讓開發者示範這個功能。當然，如果友善把 CL 的代碼內建到你的開發環境，你也可以自己親自嘗試。

4.在代碼稽核過程中，對功能的考慮還包含一種重要場景：CL 中包含一些“并行計算”，可能會帶來死鎖或競争條件。運作代碼一般很難發現這類問題，通常需要（開發者和稽核者）仔細考慮，以確定不會引入新的問題。（這也是不要引入并發模型的一個好理由，因為它可能引入死鎖或競争條件，同時也增加了代碼稽核和代碼了解的難度。）

5.4、性能

1.這段代碼如果資料量大，性能是否有問題？有沒有更好的實作方式？

案例：多個for循環無用業務

5.5、複雜性

1.是不是 CL 可以不必這麼複雜？在 CL 的每個層次上檢查——哪一行或哪幾行是不是太複雜了？功能是否太複雜了？類（class）是否太複雜了？“太複雜”的定義是代碼閱讀者不易快速了解。 同時意味着以後其他開發者調用或修改它時，很容易引入新的缺陷。

2.另一種類型的複雜是過度工程化（也稱為過度設計）。開發者在設計代碼時太過于在意它的通用性，或在系統中加入了目前不需要的功能。稽核者應該特别警惕過度工程化。鼓勵開發者解決 目前 應該解決的問題，而不是開發者推測将來 可能 需要解決的問題。将來的問題，等碰到的時候，你才能看到它的實際需求和具體情況，到那時再解決也不遲。

5.6、日志

日志列印是否簡明扼要，是否有助于線上問題排查；關鍵環節是否列印了日志

5.7、異常

異常處理，是否符合服務可用率治理規範，確定增量代碼不腐化已經通過可用率星級認證的接口；

5.8、測試

1.同時要求開發者提供 CL 對應的單元測試。單測代碼與開發代碼應放到同一個 CL 中，除非碰到緊急情況

2.確定 CL 中的測試是正确的、明智的、有用的。測試代碼并不是用來測試其自身，我們很少為測試代碼寫測試代碼——這就要求我們確定測試代碼是正确的。

3.當代碼出問題時，是否測試會運作失敗？如果代碼改變了，是否會産生誤報？是否每個測試都使用了簡單有用的斷言？不同的測試方式是否做了合适的拆分？

謹記：測試代碼也是需要維護的代碼。不要因為不會編譯打包到最終的産品中，就接受複雜的測試代碼。

5.9、每行代碼

1.在稽核代碼時，仔細檢查每行 代碼。某些檔案，如資料檔案、生成的set、get代碼或較大的資料結構，可以一掃而過。但是人寫的代碼，如類、功能或代碼塊不能一目十行，我們不應假設它是正确的。有些代碼得尤其小心——這需要你自己權衡——至少你應該确認你 了解 這些代碼在做什麼。

2.如果代碼很難讀懂，那就放慢稽核速度，告訴開發者你沒讀懂代碼，讓他解釋與澄清，之後繼續稽核。如果你讀不懂代碼，很有可能其他工程師也不懂。實際上，這麼做也是在幫助以後的工程師，當他讀到這段代碼時更容易了解代碼。是以，讓開發者解釋清楚。

如果你了解這些代碼，但是感覺自己不夠資格稽核它，確定找到一個夠資格的人來稽核，尤其是比較複雜的問題，如安全、并發、可通路性等等。

5.10、上下文

1.把 CL 放到一個更廣的上下文中來看，通常很有用。在稽核工具中，我們往往隻能看到開發者修改的那部分代碼。更多時候從整個檔案的角度來讀代碼才有意義。例如，有時候你隻看到添加了幾行代碼，但從整個檔案來看，你發現這幾行代碼添加到了一個100行的方法中。在增加之後，需要把它拆分成更小的方法。

2.把 CL 放到系統的上下文中來考慮也很有用。CL 能提升系統的代碼健康狀況，還是讓系統變得更複雜、更難測試？大多數系統變得很複雜都是由每個細小的複雜累積而成的，在送出每個 CL 時都應避免讓代碼變得複雜。

5.11、文檔

1.如果 CL 修改了編譯、測試、互動、釋出的方式，那麼應檢查下相關的文檔是否也更新了，如 README 檔案、CF頁面，或其他所有生成的參考文檔。

2.如果 CL 删除或棄用（deprecate）了一些代碼，考慮是否也應删除相應的文檔。如果沒有這些文檔，讓開發者（ CL 送出者）提供。

5.12、注釋

1.開發者是否寫了清晰的注釋？是否所有的注釋都是必須的？通常當注釋解釋為什麼這些代碼應該存在時，它才是必須的，而不是解釋這些代碼做什麼。如果代碼邏輯不清晰，讓人看不懂，那麼應該重寫，讓它變得更簡單。當然，也有例外（例如正規表達式和複雜的算法通常需要注釋來說明），但大部分注釋應該提供代碼本身沒有提供的資訊，如這麼做背後的原因是什麼。

2.有時候也應該看一下這個 CL 相關的曆史注釋。例如，以前寫的TODO，現在可以删掉了；某段代碼修改了，其注釋也應随之修改。

注意，注釋與類、子產品、功能的 文檔 是不同的，這類文檔應該描述代碼的功能，怎樣被調用，以及被調用時它的行為是什麼。

5.13、代碼樣式

1.在京東，我們所有的主要程式設計語言都要遵循京東代碼規範，確定 CL 遵守代碼樣式指南中的建議。

2.如果發現某些樣式在代碼樣式指南中并未提及，在注釋中加上“Nit”，讓開發者知道，這是一個小瑕疵，他可以按照你的建議去做，但這不是必須的。不要因為個人的樣式偏好而導緻 CL 延遲送出。

3.作者在送出 CL 時，代碼中不應包含較大的樣式改變。為這樣很難比較出 CL 中有哪些代碼修改，其後的代碼合并、復原會變得更困難，容易産生問題。如果作者想重新格式化檔案，應該把代碼格式化作為單獨的 CL 先送出，之後再送出包含功能的 CL

5.15、好的方面

如果在 CL 中看到一些比較好的方面，告訴開發者，尤其是當你在稽核代碼時添加了評論，他在回複你的評論，嘗試向你解釋的時候。稽核者往往隻關注代碼中的錯誤，他們也應該對開發者的優秀實踐表示鼓勵和感謝。有時候，告訴開發者他們在哪些方面做得很好，比告訴他們在哪些方面做得不足更有價值。

6、怎樣寫代碼稽核的評論？

1.禮貌，保持友善

2.解釋原因：闡明你的意圖、你正在遵循的最佳實踐、你在提升代碼健康程度

3.給出明确的資訊，指出問題所在，讓開發者最後做決定。

4.鼓勵開發者簡化代碼，給代碼添加注釋，而不是向你解釋為什麼這麼複雜

7、代碼評論被拒絕，應如何處理？

1.開發者和稽核者都可能對代碼提出修改建議，但應先考慮開發者是否正确。若開發者正确，可忽略評論；否則，稽核者需解釋建議必要性。

2.若稽核者堅持修改，即使需額外工作也值得，因為提升品質是持續過程。

3.有時需多輪解釋，保持禮貌。

4.常見拒絕原因是想盡快完成，建議現在就開始清理，或配置設定給自己 bug 以避免遺忘，加上 TODO 注釋和 bug 編号。

四、代碼開發者指南

從開發者的角度來看，我們也需要了解一些開發者的指南。這些指南包括：

1.遵循編碼規範和最佳實踐，編寫良好的CL描述：作為開發者，我們應該遵循編碼規範和最佳實踐，確定代碼的品質和可讀性。

2.CL送出的原子性，如何定義小CL？

3.如何處理稽核者評論及修改代碼？

本文包含開發者怎樣讓代碼稽核容易通過的最佳實踐。在讀完本指南後，相信能夠讓你的稽核品質更高，速度更快。

1、編寫良好的 CL 描述

CL 描述内容應該提供足夠的資訊，讓CR更加清晰。它包含了改了什麼 與 為什麼 這麼修改？

1.1、良好的 CL 描述

附Promise這個CL，清晰描述了需求PRD（連結），及核心邏輯，DUCC開關及單測描述

1.2、糟糕的 CL 描述

“修複 bug”是一個很不恰當的描述。哪個 bug ？你做了哪些事情來修複它？通通都沒有。類似糟糕的描述還包括：“增加更新檔”，“删除代碼”，“沒有描述”

2、原子性送出

《持續傳遞 2.0》的四大工作原則是：堅持少做、持續分解問題、堅持快速回報和持續改進并衡量。這些原則可以不斷縮短持續傳遞“8”字環的運作周期，提升使用者回報速度，進而提高業務的靈活性。它們在代碼送出與 Code Review 中的應用就是：送出的原子性。

2.1、為什麼應該寫小 CL？

小 CL 有如下優點：

1.評審效率更高：将大段的CL拆分成多個小段CL。這樣可以讓評審者更容易集中幾分鐘（5分鐘比30分鐘容易）在關鍵部分，提高評審效率。

2.回報更及時：如果開發者花費了很大的精力開發了一個大 CL，直到稽核的時候才知道整個開發的方向錯了，那麼之前的所有時間就全浪費了。

3.引入新缺陷機率更低： 如果修改的内容比較少，自然稽核人的效率會更高，開發者與稽核者都更容易判斷是否引入了新的缺陷。

4.更易于設計： 完善小 CL 的設計和修改要容易得多，多次微小的代碼品質提高比一次大的設計改變更容易。

5.更容易合并代碼： 大 CL 在合并代碼時會花費很長的時間，在合并時需要花費大量時間，而且在寫 CL 期間可能不得不頻繁地合并。

6.更容易回退：一個大 CL 開發的時間比較長，這意味從開發到代碼送出這段期間，代碼檔案的變更會比較多。當回退代碼時，情況會變得很複雜，因為所有中間的 CL 很有可能也需要回退。

請注意：稽核者有權因為你的 CL 太大而拒絕它。

2.2、那麼如何定義“小”？

一般而言，一個 CL 的大小就應該是 獨立功能的修改。這意味着：

1.盡量将一個CL的大小最小化，它隻做一件事。每個CL應該隻關注一個特定的功能或任務，而不是整個功能。這樣可以使稽核者更容易了解和評估CL的内容，并減少不必要的複雜性和混亂。可與稽核者進行讨論，以确定CL的适當大小。可以共同探讨CL是否涵蓋了足夠的功能，并且能夠提供足夠的上下文來了解CL的目的和影響。通過溝通和合作，可以找到最佳的平衡點。

2.確定CL中包含了所有必要的資訊，以便稽核者可以了解CL的目的和内容。除了CL本身的代碼之外，還應包括對CL的描述、已存在的代碼或之前已經稽核過的相關CL的資訊。這樣稽核者可以更好地了解CL的背景和上下文，進而做出準确的判斷。

3.在送出CL之後，確定系統仍然能夠正常運作。無論是對于使用者還是開發人員來說，系統的正常運作是至關重要的。是以，在編寫CL時，請確定不會引入任何破壞性或不相容的更改。

4.如果代碼難以了解，可能是因為CL的大小還不夠小。如果需要添加一個新的API，最好将其與相應的使用方法一起包含在同一個CL中。這樣可以友善稽核者了解如何使用該API，同時也友善後續的開發者使用和維護。此外，這還可以有效防止送出的API無人使用的情況發生。

5.定期回顧和改進您的CL過程。通過反思和總結經驗教訓，您可以找到可能存在的問題和改進的空間。持續優化您的CL過程将有助于提高整體的開發效率和代碼品質。

沒有直覺的标準判斷 CL “太大”應該符合哪些條件。

2.3、什麼時候可以有大 CL？

當然，也有一些例外情形，允許 CL 比較大：

•删除一個檔案與修改一行沒有太大差別， 因為它不會花費稽核者太多時間。

•有時候，一個大 CL 可能是由可靠的自動代碼重構工具生成的，稽核者的工作主要是檢查它是否做了它應該做的工作。雖然符合以上提到的注意事項（例如合并和測試），這類 CL 也可能比較大。

2.4、注意事項

1.CL之前研發通過插件（idea內建JoyCoder，京東Idea插件、sonar等檢查文法之類）檢查并且修複各種代碼樣式問題。

2.把系統重構及技術改造的單獨CL

3.把測試代碼包含到對應功能的 CL中

4.不要破壞編譯，影響他人

3、如何處理稽核者的評論

在發出 CL 之後，稽核者一般會給出回報（評論），讓你修改代碼。以下是一些建議，可以幫助您在代碼稽核過程中處理稽核者的評論：

3.1、保持好心态

1.先思考自己是否有改進的空間。仔細考慮稽核者是否在回報中提供了有價值的内容，可以幫助提高代碼庫的品質。你的第一個問題應該永遠都是，“稽核者說得對嗎？” 如果确認你是對的，那就解釋為什麼你的方法比較好。

2.保持冷靜和專業。無論稽核者的評論是正面的還是負面的，都要保持冷靜和專業的态度。不要将稽核者的評論視為個人攻擊或人身攻擊，而是将其視為對您工作品質和代碼庫品質的建議和改進的機會。

3.從建設性的角度去了解評論。稽核者可能以批判性的語氣表達他們的評論，但作為開發者，您應該努力從中尋找建設性的意見和建議。問問自己，“我能從這個評論中學到什麼？如何改進我的代碼？”然後根據這些建議來調整和改進您的代碼。

4.不要帶着情緒回複評論。在代碼稽核過程中，違反專業禮儀是非常嚴重的事情。如果您感到生氣、惱火或受到冒犯，最好先離開電腦一會兒，或者做其他事情來平靜自己的情緒。確定您可以以禮貌和友好的方式回複稽核者的評論。

5.尊重稽核者的專業知識和經驗。稽核者通常具有豐富的程式設計經驗和專業知識，他們的意見和回報對于提高您的代碼品質和産品的品質非常重要。尊重他們的專業意見，并盡可能采納他們的建議進行改進。

6.尋求澄清或進一步解釋。如果您對稽核者的評論有任何疑問或不了解的地方，不要猶豫向他們尋求澄清或進一步的解釋。這有助于消除任何誤解，并確定您正确了解了對方的意見和建議。

7.提供适當的回應。在回複稽核者的評論時，盡量提供有建設性的回答和解決方案。如果您不同意對方的觀點，可以提出您的理由并提出相應的解決方案。避免争論或陷入無意義的争論中。

8.接受批評并持續改進。稽核者的評論可能是為了幫助您改進自己的工作和代碼庫的品質。接受批評，并将其視為一個學習和成長的機會。通過持續改進和修正錯誤，您可以提升自己的編碼能力和産品品質。

3.2、修複代碼

1.澄清代碼本身。當稽核者表示對您的代碼中的某些内容不了解時，首先嘗試以清晰和簡潔的方式澄清代碼的目的和功能。確定您能夠用簡單明了的語言解釋代碼的邏輯和實作方式。

2.添加注釋來解釋代碼。如果無法通過澄清代碼本身來解決稽核者的疑問，您可以添加适當的注釋來解釋為什麼這段代碼這樣寫。注釋應該簡明扼要地概括代碼的功能、目的和關鍵步驟，以便其他開發者能夠更好地了解和維護代碼。

3.清理和重構。如果稽核者無法了解某段代碼，很有可能其他的代碼閱讀者也會遇到相同的困惑。在這種情況下，考慮對代碼進行清理和重構，以提高其可讀性和可維護性。删除不必要的複雜性，使用清晰的命名約定和适當的代碼結構，以幫助其他開發者更容易了解和閱讀代碼。

4.鼓勵開放的溝通和讨論。在處理稽核者的不了解時，保持開放和積極的溝通态度非常重要。與稽核者一起探讨問題的根源，尋求共同的解決方案，并盡可能提供清晰的解釋和支援。這種開放的溝通有助于建立信任和合作，推動問題的解決和改進的程序。

五、代碼評審的沖突解決

以下是一些建議，可以幫助您在與稽核者之間出現沖突時進行有效的溝通和解決：

1.強調代碼的重要性。在與稽核者讨論問題時，始終強調代碼的重要性和正确性。指出代碼是解決問題的關鍵，而不是個人攻擊或人身攻擊的借口。

2.嘗試達成共識。首先，努力與稽核者達成共識并找到雙方都可以接受的解決方案。這可能涉及妥協、解釋各自的觀點和了解對方的立場。通過開放和建設性的讨論，尋找共同的目标和原則。

3.參考代碼規範和CR标準。如果無法達成共識，可以參考代碼規範和CR标準等文檔來提供指導和準則。這些文檔通常包含最佳實踐、編碼規範和代碼審查要求，可以作為解決沖突的參考依據。

4.面對面溝通。當面臨無法解決的問題時，考慮面對面與稽核者進行溝通。面對面的會議可以提供更多的上下文和細節，有助于更好地了解彼此的觀點，并更有效地解決問題。確定在會議之後記錄下讨論的結果，并在代碼稽核評論中進行回報。

5.尋求團隊的支援和意見。如果面對面的溝通仍然無法解決問題，可以尋求其他團隊成員（如架構師、TL）的意見和支援。他們可能能夠提供不同的視角和解決方案，幫助您更好地處理沖突。讓TL參與讨論并做出最終決定，以確定問題得到适當的解決和跟進。

6.保持專業和尊重的态度。無論遇到什麼情況，都要保持專業和尊重的态度對待稽核者和整個團隊。避免争吵、指責或情緒化的反應，而是以理性和冷靜的方式處理沖突，并緻力于找到最佳的解決方案。

六、緊急情況

以下是一些建議，可以幫助您處理緊急的CL和相關的代碼稽核流程：

1.快速響應并加快稽核流程。在緊急情況下，稽核者應該優先考慮代碼的正确性和解決緊急問題的能力，盡快回複稽核者的請求，并盡力加快稽核流程。這可能包括加快代碼評審、測試和驗證的速度，以及與團隊成員協調解決問題的時間。

2.完成緊急情況後進行更全面的稽核。一旦緊急情況處理完畢，您可以回過頭來進行一次更全面的代碼稽核。這次稽核可以檢查代碼的整體品質和一緻性，并確定所有的功能和修複都按照最佳實踐進行編寫和維護。

3.記錄和總結經驗教訓。緊急情況發生後，及時記錄下您的處理過程和經驗教訓。回顧這些經驗可以幫助您改進未來的應對政策，并為類似的情況提供參考依據。

七、CodeReview-AI大模型

1.上面描寫的都是人去CodeReview，但靠人力太費事費力，而且團隊每個人的水準不一樣，這樣也會導緻CR的效果也不一樣。是以我們需要思考如何利用科技的力量，比如大模型等工具去CodeReview，通過定義好的代碼規範和代碼比對，給出建議等，提升代碼效率的同時也保障了代碼品質。

八、總結

總之，在進行代碼評審時，我們需要從評審者和開發者的不同角度出發，關注不同的方面。通過合理的評審和開發指南，提高代碼品質和團隊協作效率。上面描述的方式還需要大家在實踐過程中進行持續改進，并根據團隊的實際情況進行調整：

1.考慮團隊的特點和需求。每個團隊都有自己獨特的特點和需求。在制定代碼審查方法和流程時，要充分考慮團隊的規模、項目類型、開發語言和技術棧等因素。確定所選的方法和流程與團隊的實際情況相适應。

2.定期回顧和改進。代碼審查是一個持續不斷的過程，需要定期回顧和改進。定期與團隊成員讨論和評估目前的代碼審查方法和流程，了解他們的體驗和意見。根據回報和經驗教訓進行必要的調整和改進。

3.培養學習氛圍和文化。代碼審查不僅是為了解決問題和提升代碼品質，也是一個學習和成長的機會。鼓勵團隊成員互相支援、分享知識和經驗，并建立一種積極進取的學習文化。通過教育訓練、分享會和團隊活動等方式來促進學習和知識傳遞。

4.保持持續改進的動力。代碼審查是一個長期而持續的過程，需要不斷努力和改進。保持對代碼品質的關注和追求卓越的動力，将代碼審查視為一個持續改進的機會，并不斷尋求提高團隊整體代碼水準的方法。

本文旨在為大家提供參考和借鑒。同時也歡迎大家對文章進行指正和建議，以便更好地完善我們的實踐經驗。如果您有更好的實踐經驗，也歡迎與我們交流分享。謝謝！

參考文獻：

Google Engineering Practices Documentation

谷歌代碼審查指南 譯文：https://jimmysong.io/eng-practices/docs/review/