1 為什麼需要CodeReview

1. 保證程式碼質量
2. 通過他人的建議提升技術認知

2 CodeReview的流程

1. 制定標準：進行CodeReview前一定要制定好標準。否認提交人和審閱人之間很肯定會引起很多無意義的爭執，導致時間耗費增加。
2. 學習標準：為了達成共識，需要大家一起學習標準，最終達成共識。
3. 評審人前置準備：根據專案情況選擇合適的人來評審，同時評審人需要為程式碼評審做好準備。包括需求學習、方案學習。
4. 提交人前置準備：為了提高CodeReview效率，應該對程式碼提交制定相應標準，這樣可以提高效率。
5. 程式碼評審：根據標準原則及工程經驗提出意見
6. 總結分析迭代標準：根據CodeReview中產生的問題，進一步學習總結，迭代標準，改進下一次Review的效率。

上述是CodeReview的一種流程。這6步驟通常會形成一個閉環，持續迭代。接下來幾部分將詳細介紹這些過程的各個環節。

3 制定標準

3.1 為什麼要制定標準

讓團隊對問題達成一致，避免無意義的衝突和時間消耗。同時出現問題時有一個可參考的解決標準。

3.2 如何制定標準

• 有意義：制定的標準對於當前現狀具有實際意義。能解決當前面臨的主要問題。而不是開始就整理一大堆複雜且與主要矛盾無關的標準。
• 充分調研：定標準的意義是讓團隊對問題能達成共識，因此需要與大家進行充分的討論。而不是某個人主觀臆斷而定義。
• 清晰明確：為了讓大家達成共識，標準應該是清洗明確無二義性。
• 可執行：標準最終是讓團隊參照並執行，因此大而虛最終無法執行的標準是不可行的。

3.3 制定哪些內容

3.3.1 標準內容制定

• 衝突解決方案：如果review過程中出現衝突如何解決
• 權利與責任：出現問題提交人與稽核的應承擔的責任
• 特殊情況解決方案：出現緊急故障時review的過程。例如跳過review或僅又review核心部分程式碼。或針對其它特殊情況進行特殊制定。
• review檢查點：一次review應該關注哪些內容

3.3.2 提交人提交標準制定

進行一次CodeReview並不是隨意就能發起。這樣進行CodeReview的效率會很低。因此也需要滿足一定條件。

• 自測：一定要先行自測完畢
• 選擇評審人：有限選擇熟悉相關業務的同伴作為評審人
• 提交描述：對自己提交的內容要有準確簡介的描述。
• 評審程式碼量：一次評審程式碼量儘量做好控制。利用分治的原則，避免一次提交過多程式碼。這樣拆解提高評審效率。例如一次提交的程式碼量控制在500行內。
• 評審流程說明：要告知評審人提交的程式碼閱讀流程是什麼。
• 評審人評論跟進：對於評審人的程式碼評論要給出說明或進行相應的改進，並重新提交審閱。

3.3.2 評審人標準制定

• 通過標準：根據業務特點制定code review的檢查項。
• 反饋：應儘快給與提交人反饋，避免時間過長造成遺忘。
• 評論：code review也涉及到人與人間的交流，因此要使用合適的方式對提交人程式碼進行評論及交流。給出必須修改、可忽略、建議修改等評註。

4 團隊學習

有了標準後需要讓大家達成一致，如果有不一樣的意見也可得到及時反饋。可以藉助內容分享讓大家進行。

5 業務梳理

評審的前提是雙方對業務都有一定認識，因此需要同步需求概況。
同時對開發者的設計過程要有一定了解。有了這些背景就能更好的進行評審。

6 程式碼評審

根據檢查項和業務狀態對程式碼進行評審，並給出建議。通常需要關注下列資訊。

• 完整度：看一次提交是否完整的實現了本次的業務需求。
• 單元測試：檢查核心功能是否有單元測試且對於邊界條件能夠通過測試。
• 註釋：對於複雜的業務邏輯，如果不能通過程式碼本身的命名來表現含義。需要檢查是否有有效註釋進行說明。
• 技術問題：例如是否存在併發問題、快取同步問題等、是否能應對異常情況，魯棒性是否滿足、是否易於理解。技術問題就要結合業務梳理階段與技術方案來一起進行評審。

7 總結分析迭代標準

在評審結束後，可能制定的標準不能滿足所有條件。因此需要進行溝通迭代進行標準升級。

參考資料

[1]google的code review機制，https://juejin.cn/post/6844903944175484936