簡介：在行業激烈競爭業務快速運轉的今天，如何在實現快速交付的同時保證代碼質量一直以來都是技術團隊反復探討的話題之一。代碼評審是結對編程相互切磋相互學習的方式，是敏捷開發模式中的一個重要環節，是保障代碼質量的重要手段。有效的代碼評審可降低故障率，本篇我們重點介紹團隊如何在云效上做好代碼評審。?

在行業激烈競爭業務快速運轉的今天，如何在實現快速交付的同時保證代碼質量一直以來都是技術團隊反復探討的話題之一。代碼評審是結對編程相互切磋相互學習的方式，是敏捷開發模式中的一個重要環節，是保障代碼質量的重要手段。有效的代碼評審可降低故障率，本篇我們重點介紹團隊如何在云效上做好代碼評審。?

代碼質量可以通過兩個維度來度量：一是代碼的缺陷情況，二是代碼可讀性。代碼缺陷小則引發線上故障影響業務正常運行，大則可能造成企業重大經濟損失甚至信用受損，重則引發社會動蕩；而代碼可讀性也尤為重要，可讀性差則維護成本高，修改相關模塊代碼無異于埋雷，一不小心就會炸。

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

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

** 云效代碼評審解決方案**

1、如何設置卡點

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

• 要求合并前通過代碼評審

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

• 要求合并前通過自動化執行檢查

提供官方插件 Java 代碼規約掃掃描和敏感信息檢測，且支持卡點設置。
具體參見代碼掃描：
鏈接文字

2、評審人選擇

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

• 保護分支默認評審人

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

• CodeOwner 模式

理想情況下的 Code Review，是評審人員就是最熟悉這塊代碼的同學，但是實際上Author并不一定知道誰應該 review 自己的改動。CodeOwner 機制就是去維護一個文件，指明哪些路徑下的哪些文件被誰 own 應該誰去 review，當 push 更改中包含這些文件時，就會將 own 這些代碼的人自動加到評審人中。

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

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

3、評審人智能推薦

項目組結構復雜，寫好了代碼，不知道應該交給誰評審最合適？
項目人數較多，每次選擇評審人耗時耗力？
使用評審人智能推薦服務，不用再浪費時間和精力尋找當前代碼模塊負責人了，結合智能算法，我們將為你推薦最佳評審人，快速推進評審流程。

• 推薦規則

評審人推薦算法主要基于以下條件衡量分析：
文件特征：評審人評審過同一個文件或同一個目錄下的文件；
評論特征：評審人評論過同一個文件或同一個目錄下的文件；
分支特征：評審人參與過同一個目標分支的評審；
歷史評審人特征：評審人被當前發起人指派過；
權限特征：用戶在庫內的權限情況；

• 開啟服務

在庫設置-合并請求設置中開啟「評審人智能推薦」服務。
開啟時需要授權服務。

• 推薦評審人

開啟服務后，在創建合并請求或合并請求詳情頁的選擇評審人下拉框中，算法命中推薦的評審人將頂置，你可以方便的進行選擇。

**代碼評審最佳實踐**

如何做好代碼評審的最佳實踐

• 做好提交

將提交做小做好，寫小提交就是將問題解耦：“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 有意識這不是一個完整的功能，且無法合并。

• 問題追蹤

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

• 定期度量

通過數據洞察獲得團隊質量情況，有策略的提升團隊技術能力。代碼庫統計模塊更多能力敬請期待。

-END-
長按識別上圖二維碼進群，更多干貨、優惠活動等你解鎖
點擊:https://codeup.aliyun.com/?channel=yy_rccb鏈接文字
進入產品進行體驗
快來試試，若有收獲，點個贊吧！！！

原文鏈接：https://developer.aliyun.com/article/779726?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的云效DevOps实践-代码评审的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。