研發效能領域洞察 | 敏捷開發實戰（一）：Code Review 縱覽

時間 2019-11-07

標籤研發效能領域洞察敏捷開發實戰 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 時，重點在查找問題，隨着問題的逐漸減小和習慣的逐步養成，交流及知識共享會成爲重點，當有大批新人加入時，查找問題將又成爲重點，經過這樣周而復始的過程提升代碼質量，知識共享，幫助開發者成長。測試

03 如何作好 Code Review ？

Code Review 這項活動跟人的因素密切相關，是否有效運做跟團隊狀態、技術信仰和 TL 的訴求都有很大的關係。所以，在 Code Review 時，要在乎識、方法、心態上培養，保持良好的 Code Review 習慣，會在各方面有很大的提高，如下將從這三方面進行展開：優化

意識

Code Review 的目的是提高代碼質量，同時促進團隊內部知識共享，幫助更多人更好地理解系統。所以，咱們在乎識上要明確目標和原則：設計

發現代碼的正確性。code
不只是在 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. 選擇合適的工具：「工欲善其事，必先利其器」。嚴格的流程會扼殺創造力，可是鬆散的流程又意味着沒人知道評審是否有效，甚至是否發生。而我的批評的社會效應，又會損傷士氣。業內的實踐經驗證實輕量級代碼評審是高效的。

心態

不管是代碼做者，仍是評審者，都須要一種積極向上的正面的態度，做者須要可以虛心接受別人的建議，由於別人的建議是爲了讓你作得更好；評審者也須要以一種積極的正面的態度向做者提意見，由於那是和你在一個戰壕裏的戰友。團隊須要維持這樣一種態度，發現問題意味着代碼開發者和評審者做爲一個團隊去改進產品的質量成功了。而不是「代碼開發者產生了一個缺陷，而評審者負責去發現它」。