敏捷開發實戰（一）：Code Review 縱覽

敏捷開發實戰系列

站在螞蟻金服的視角，自主研發的中介軟體、資料庫、研發平臺等金融科技引領著企業數字化的技術趨勢。其中，以螞蟻研發效能為代表，催生了很多賦能行業的方法論和工程實踐，基於對研發效能領域的洞察，特別推出 敏捷開發實戰 系列文章，今天將從程式碼層面開始，對Code Review這個基礎而重要的環節進行剖析。

作者簡介 

雨知

螞蟻金服 產品專家

李素石，花名雨知，螞蟻金服研發效能部產品專家。多年的配置管理工作，豐富的程式碼服務、研發模式實踐經驗。

01

前言

Code Review ，中文稱為程式碼評審，有時候也稱為程式碼審查。引用維基百科的定義，Code Review 是計算機原始碼的系統性檢驗（有時被稱為同行評審）。其目的在於找到開發初期所忽略的錯誤，從而提高軟體的整體質量。審查的形式多種多樣，如結對程式設計，非正式走查，正式檢查等。卡珀斯·瓊斯（Capers Jones）分析了超過 12,000 個軟體開發專案，其中使用正式程式碼審查的專案，潛在缺陷發現率約在 60-65% 之間，若是非正式的程式碼審查，潛在缺陷發現率不到 50%。大部分的測試，潛在缺陷發現率會在 30% 左右。

02

好的 Code Review 能帶來什麼？

發現問題： 通過評審發現問題增進程式碼質量，這是最常見的理解，是對 Code Review 的好處的最廣泛的認識。

知識共享： 程式碼評審是一個傳遞知識的手段，可以讓其他不熟悉程式碼的同學知道作者的意圖和想法，儘管評審者不能像作者一樣十分了解，但他會熟悉設計和架構，起到 backup 的作用。

幫助成長：程式碼評審是純社會性的，也為團隊提供了一個培養開發者的機會。

一般來說，團隊剛開始做 Code Review 時，重點在查詢問題，隨著問題的逐漸減少和習慣的逐步養成，交流及知識共享會成為重點，當有大批新人加入時，查詢問題將又成為重點，通過這樣周而復始的過程提高程式碼質量，知識共享，幫助開發者成長。

意識

Code Review 的目的是提升程式碼質量，同時促進團隊內部知識共享，幫助更多人更好地理解系統。因此，我們在意識上要明確目標和原則：

• 發現程式碼的正確性。

• 不僅是在 review 程式碼，也是在分享和學習，提升團隊整體水平，提升團隊維護程式碼的能力。

• 高效迅速完成 code review，不能為了應付進行。

方法

1. 明確評審內容： 評審者要檢查設計的合理性以及業務邏輯十分錯誤，檢查程式碼的可讀性：

• 體系結構和程式碼設計

• 程式碼風格

2. 提升評審質量和效率

• 控制每次評審的程式碼數量 根據 smartbear 在 Cisco 程式碼評審研究顯示了為了得到優化的效率，開發員的評審量要低於一次 200-400 行程式碼（LOC）。超過這個量，搜尋缺陷的能力就會降低。以這個速度，您可以找到 70-90% 的缺陷。換句話說，如果存在 10 個缺陷，那麼您可以找到其中的 7 到 9 個。

• 隨著開發平臺和開發語言的不同，最優的程式碼審查量有所不同，但是 限制每次審查的數量 確實非常必要，因為這個過程是高強度的腦力密集型活動。時間一長，程式碼在審查者眼裡只是字母，無任何邏輯聯絡，自然不會有太多的產出。

• 保障較優的評審效率 程式碼評審需要花費一定的時間，但快速評審並不總是好的。smartbear 在 Cisco 程式碼評審的研究結果顯示檢查率低於“300-500 LOC/小時”時，可以得到優化的結果。下圖顯示：伺服器端每小時超過 400 LOC 的評審速度會降低效率，當評審量超過 500 行程式碼檢查效率就會顯著下降。

• 確認問題確實得到修復 對於評審程式碼發現的問題，修復它們是順利成章的事情，我們需要有一種好的方法，來追蹤評審期間發現的問題，並確保問題確實得到了修復。

• 多人評審   儘可能的讓不同的人 review 你的程式碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的程式碼，基本上來說，不要超過3個人，這是一個可以圍在一起討論的最大人員尺寸。

3. 總結優化： 有些團隊的 Code Review 活動堅持不下來或逐步流於形式，其中一個主要原因是過程中缺乏定期回顧和總結，從而不知道如何有效促進和幫助團隊更好的運作。為程式碼評審建立可定量的目標，這樣可以幫助改進流程。

4. 選擇合適的工具： “工欲善其事，必先利其器”。嚴格的流程會扼殺創造力，但是鬆散的流程又意味著沒人知道評審是否有效，甚至是否發生。而個人批評的社會效應，又會損傷士氣。業內的實踐經驗證明輕量級程式碼評審是高效的。

心態

無論是程式碼作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在一個戰壕裡的戰友。團隊需要維持這樣一種態度，發現問題意味著程式碼開發者和評審者作為一個團隊去改進產品的質量成功了。而不是“程式碼開發者產生了一個缺陷，而評審者負責去發現它”。

螞蟻金服程式碼服務平臺為使用 Gitflow + 合併請求的方式進行 Code Review 的同學打造適用的CR平臺，實現整體程式碼服務的升級，其中合併請求的操作和 Code Review 密不可分。

合併請求是程式碼協作的基礎。 顧名思義：這是一個合併請求，從一個分支合併到另一個分支。合併請求可能是新需求、優化改造、缺陷修復等。典型的處理過程包括：如何提交合並請求？如何對合並請求進行評審以便確定是否接受？誰來處理合並？合併後的通知機制等。 通過合併請求，可以實現：

• 比較兩個分支之間的變化

• 線上檢視和評論程式碼修改，並記錄問題狀態

• 評審設定支援多種評審需求，如多人評審等

• 合併請求設定可以控制合併准入

• 展示合併衝突列表

• 壓制合併（squash merge）讓提交歷史記錄更清晰

• 合併請求版本，基於每次 push 產生，可以選擇並比較這些合併請求差異的版本

同時，合併請求的准入設定可以有多種情況。例如，團隊中的開發人員需要提交程式碼：

• 建立一個新的分支，並修改提交程式碼

• 建立合併請求提交對程式碼的變更

• 團隊其他成員在合併請求的評審記錄中進行反饋討論

• 提交者接到郵件通知，根據評審意見修改解決

• 這些檢查都通過後，批准合併

以上介紹了一些 Code Review 的實踐，這些方式是否適用還需要大家在各自的實踐過程中進行驗證並根據實際情況進行相應的調整，以達到 Code Review 的目標。有任何疑問或者經驗交流，歡迎通過公眾號回覆給我們，讓我們一起 Code Review！

長按識別二維碼關注我們

P.S.

螞蟻金服研發效能團隊招募進行中， 解決方案架構師、技術運營、資料研發專家、技術專家、技術支援專家、 產品專家、測試平臺高階開發工程師、程式碼分析技術專家 等眾多崗位持續開放，讓我們共同開赴DevMind/ DevOps /DevServices三大戰場，助力內部及外部夥伴研發效能的持續提升:rocket::rocket::rocket:

如果你對任何崗位感興趣，請留下聯絡方式，或者發簡歷到： [email protected]

▼  點選獲取更多職位詳情