背景

在行業激烈競爭業務快速運轉的今天，如何在實現快速交付的同時保證代碼質量一直以來都是技術團隊反復探討的話題之一。

代碼質量可以通過兩個維度來度量：一是代碼的缺陷情況，二是代碼可讀性。代碼缺陷小則引發線上故障影響業務正常運行，大則可能造成企業重大經濟損失甚至信用受損，重則引發社會動蕩；而代碼可讀性也尤為重要，可讀性差則維護成本高，修改相關模塊代碼難度大。Google最早引入CodeReview的初衷就是為了保證代碼具有良好的可讀性，并將Readability Review延用至今。

有效的代碼評審可降低故障率，本篇我們重點介紹團隊如何在云效上做好代碼評審。

用戶的訴求或問題

• 沒有統一的流程管控，團隊同學基本不做評審，質量無法得到保障。

• 作為開發者在創建代碼評審時，不清楚改動應指派哪些評審人。

• 如何做好代碼評審。

云效代碼評審解決方案

設置卡點

保護分支允許管理員根據團隊的workflow，為單個分支或分支規則建立合適、靈活的分支管控，如：發布分支不允許所有人push，必須通過代碼評審才能merge，以及一些merge的卡點條件。合并檢查與分支權限協同管控，能為團隊提供更加靈活可控的開發工作流程。設置卡點后，代碼庫下創建符合該保護分支規則的合并請求，均走該卡點配置。

1、要求合并前通過代碼評審與自動化執行檢查

打開對應代碼庫的設置頁面，點擊分支設置，新建保護分支規則（以master分支為例）。

設置人工評審卡點，如評審最少通過人數、什么角色成員能通過等。

評審人選擇

作為開發者進行代碼提交后創建代碼評審，當代碼庫較大參與開發同學較多時，不知道該指派哪幾位同學作為本次改動的reviewer。可采用以下幾種方式：

1、保護分支默認評審人

不同研發模式，不同分支可能存在不同的負責人。代碼庫管理員可以通過將分支負責人配置為保護分支默認評審人，達到創建即指派分支負責人的效果。如：交付團隊存在基線版本，交付不同定制方，每個定制版本均是一個分支形態，均存在相應版本負責人；

2、CodeOwner 模式

Author并不一定知道誰應該review自己的改動。CodeOwner機制就是去維護一個文件，指明哪些路徑下的哪些文件應該由誰去review，當push更改中包含這些文件時，就會將負責這些代碼的人自動加到評審人中。

我們使用了一個CODEOWNERS文件來記錄代碼庫中各模塊或文件的負責人，該文件應位于分支的根目錄下。當一次評審發起后，并且代碼庫啟用了CodeOwner審核，那么系統會在評審目標分支的根目錄下，尋找CODEOWNERS文件，并從其中讀取相關設置。當文件與CodeOwner出現了1:N的情況時，例如一個文件對應了A、B、C 三位Owner，此時只要有一位CodeOwner審核通過即可。此外，評審創建時或評審分支更新后，系統會自動檢測需要參與評審的CodeOwner，并把他們自動加入審核人列表中。

CODEOWNERS文件中，對于路徑的定義采用了Glob的語法。路徑規則追加空格后，采用的形式定義相關Owner，username需使用對應Owner已驗證并綁定的郵箱。已綁定郵箱可在個人設置-個人信息查看。文件示例如下：

# 注釋行，以下為配置正文，每一行代表一個配置。
# 一個路徑規則后邊，需要有一個或多個Owner

# 用戶 Tiger@example.net,Dragon@example.net 作為所有文件的CodeOwner
** @Tiger@example.net @Dragon@example.net

# 用戶 Alan@example.net 作為所有java文件的CodeOwner
**.java @Alan@example.net

# 用戶 Ben@example.net、Carl@example.net 作為force-api目錄下文件的CodeOwner
force-api/** @Ben@example.net @Carl@example.net

# 用戶 Mike@example.net 作為force-base/src/main/java目錄下文件的CodeOwner
force-base/src/main/java/** @Mike@example.net

代碼評審最佳實踐

以下為如何做好代碼評審的最佳實踐：

• 做好提交

將提交做小做好，寫小提交就是將問題解耦：“Do one thing and do it well”。開源項目的提交通常都很小，每個提交只修改一個到幾個文件，每次只修改幾行到幾十行。每個提交應該是一個完整的功能，可能是修改某個bug或完成某個小需求的開發，commit message記錄本次 commit 詳細說明，大體分為：提交標題、主體body、sign簽名，使閱讀者能夠清晰的理解改動的背景。

• 充分描述

對于代碼評審描述應介紹本次改動的需求背景，改動范圍及影響點。一段清晰的評審描述能讓reviewer充分理解需求背景，快速開始評審，降低溝通成本。

• 小步快跑

在團隊實踐的過程中，經常碰到改動較大的評審，評審越大評審成本越高耗時越長。正確的方式是將CodeReview當做一個“日常習慣”而不是一個“蓋章動作”。只有每次提交的內容盡可能的小而獨立，才能真正讓別人幫你review。因此，我們不鼓勵到臨上線前才做CodeReview，而是當拉出的分支做完一個小的提交后，就應該開始CodeReview。如：新人入職完成了API的定義想讓同學看下模型定義上是否存在問題，就可以采用以上方式。對于開發中的代碼評審，Author可將代碼評審的標題支持設置WIP標識Work In Progress，使Reviewer有意識這不是一個完整的功能，且無法合并。

• 問題追蹤

即使大家面對面坐著，討論非常方便，事后仍要把評審中的問題記錄進系統，進行問題沉淀，并由系統跟蹤這些問題最終是否得到了解決，進行問題的跟蹤和閉環。

• 定期度量

通過數據洞察獲得團隊質量情況，有策略的提升團隊技術能力。