評審恩仇錄——我爲何願意執行代碼評審

簡介： 代碼評審帶來的好處不言自明, 但企業業務快速發展的訴求與代碼評審推進落地二者之間, 每每存在矛盾。在現在快速發展的互聯網時代，數字化、智能化已是基礎能力，單純只靠人肉審查的時代已通過去了，基於各類自動化檢查能力的加持，其實代碼評審並無想象中那麼費時費力。今天和你們聊一聊在快節奏的業務現狀下基於雲效代碼管理產品 Codeup 如何更低成本的開展代碼評審。

可貴請了年假，躺在陽光海浪仙人掌的沙灘上喝着椰汁，忽然接到系統報警電話，馬上跳起來抱着電腦處處找WIFI的場景是否似曾相識。

身爲技術開發，每逢放假巴不得燒香祈願線上穩定，若是可以在問題引入前提早扼制風險，就能夠放心享受清閒的假期了。

而代碼評審，就是扼制風險的有效手段之一。

代碼評審帶來的好處不言自明, 但企業業務快速發展的訴求與代碼評審推進落地二者之間, 每每存在矛盾。在現在快速發展的互聯網時代，數字化、智能化已是基礎能力，單純只靠人肉審查的時代已通過去了，基於各類自動化檢查能力的加持，其實代碼評審並無想象中那麼費時費力。今天和你們聊一聊在快節奏的業務現狀下基於雲效代碼管理產品 雲效Codeup 如何更低成本的開展代碼評審。

話題開始以前，先簡單介紹下代碼評審的概念。

代碼評審，英文名是Code Review，簡稱CR，它是結對編程相互切磋相互學習的方式。必定頻次的CR可以提高我們的代碼質量、促進人才成長。

1、提高代碼質量

所謂代碼質量，能夠從兩個維度來理解，一是可讀性，二是減小缺陷。

• 可讀性：Code Review 機制的誕生最先是爲了保證代碼具備良好的可讀性。代碼是一種資產，而且具備「流通性」，一般會須要多年的維護，而且面臨維護人員更替的狀況，誰都不但願本身接手的是一份「天書」同樣的代碼。使用CR的敏捷團隊更是能得到巨大的好處，由於團隊的工做是分散的，經過代碼評審可讓團隊全部人都可以有機會了解對方的代碼內容，有助於促進跨庫和整個團隊的知識共享，讓任何團隊成員均可以接管並繼續推動整個工程的演進。
• 減小缺陷：Code Review 可以發現除程序邏輯之外的設計、性能、安全、規範等多方面的問題。在這個過程當中，除了依賴評審人的專業能力外，也給了咱們更多讓自動化和智能化檢測手段介入的機會，包括對代碼規範和安全的自動化檢查、基於AI的缺陷分析和補丁推薦、合併的風險評估等。

2、促進人才成長

不少團隊都由擁有不一樣經驗的成員組成，代碼評審是一個互相檢查錯誤，互相學習代碼的機會。若是團隊的技術骨幹人員，能參與到團隊平常的架構評審、設計評審以及代碼評審中，除了可以下降出錯率，減小設計初期的風險故障外，還能夠切切實實的幫助到其餘研發人員的成長。體感更明顯的團隊會發現團隊的開發質量在逐漸提升，而且不斷在向團隊最高水平成員靠攏。

3、兩種評審場景

咱們能夠基於評審過程的嚴格程度，把評審分爲輕/重兩類，能夠根據自身業務狀況選擇最合適的評審方式。

1.輕評審不少企業管理者會以爲評審會耽誤業務的迭代速度，評審和速度是魚與熊掌不可兼得的事，固然業務最重要，評審就被天然捨棄了。

對於看重迭代速度的企業，輕評審是一個不錯的選擇，它沒有強制的規則卡點，不要求評審人必須嚴格的閱讀每一行代碼給出評審意見，結合自動化檢測的能力，在代碼合併入重要分支的時候作一次安全和質量掃描，人力投入可控，能夠更加靈活的根據當前業務情況決定是否當即合併代碼，能夠小成本的完成評審。

2.重評審

而對於一些流程嚴格，或上線代碼安全質量要求高的公司，從管理層就要求一系列評審的硬性卡點，包括自動化檢查、必須經過的評審人數、評論解決狀態等等，其中任何一條不知足都不容許合併，這種狀況就須要使用重評審特性的一系列管控能力了。

還有一些企業，不只對保護分支的合入強制管控，甚至對每一次提交都有要求，但願任何推送到服務端的代碼都要通過評審，這種場景對評審的要求很是高，而Codeup創新的集中式工做流 Agit-Flow 能夠很好的解決這個場景。

接下來咱們先看下常規的評審流程是什麼樣子的：

4、常規評審流程

代碼評審主要分爲三個階段：評審開始、評審中和評審結束。

常規流程中各個階段存在的主要困難有：

• 評審開始階段，對於發起人，須要從大量庫成員中選擇合適的評審人，填寫必要信息完成評審建立，並通知評審人及時前來評審。而對於評審人，一般會存在多個評審邀請，須要安排工做的間隙選擇適合的評審各個擊破或者用固定的時段集中評審。評審人點開評審，依次瀏覽代碼邏輯，對於比較複雜的嵌套或調用依賴，還須要去本地IDE查看內部邏輯；
• 評審過程當中，負責的評審人會基於漏洞，風格，缺陷等維度提出評論。要等待評審發起人收到通知後修復代碼，而後提交再次評審。如此迭代，直到問題被解決，評審人點擊經過評審，若是源分支和目標分支有代碼衝突的話，須要評審發起人去解決衝突，最後合併代碼。

常規的代碼評審流程主要有如下問題：

1.建立評審麻煩：評審的建立須要手動填寫大量信息，不少操做是重複勞動或是無從下手的；

2.人力投入成本高：最傳統的代碼評審是結對編程，以及團隊圓桌評審，人力的投入顯而易見。代碼評審轉移到線上後，仍然須要多人仔細校對、分析和線下討論。缺乏自動化評審手段是關鍵。

3.評審流程體驗差：評審過程當中純文本的代碼難以展示代碼的深入邏輯，代碼是立體的，部分改動的方法須要去查看定義和引用才能看出問題，不然只能是走馬觀花，效果有限，負責的評審人每每須要結合本地IDE來配合使用。評審發起人收到評論後，須要去本地修改提交後，再回複評論，路徑很長。評審的經過、合併也沒有卡點規則，任何有權限的人都能作這些操做，卻可能會忽略評審的問題沒有解決，致使本能夠提早解決的問題帶入線上生產環境。

4.評審活動狀況難評估：管理者經常但願可以衡量，團隊的成員是否真正踐行評審，保證評審質量，而不是隨意經過評審，只是走個流程。

5、雲效智能代碼評審

針對常規代碼評審存在的問題，雲效Codeup 經過智能算法和流程管控能力，讓評審更加高效。

1.提高建立速度建立評審須要填寫一堆基礎信息，雲效Codeup 努力將用戶須要輸入的內容壓縮到最少：

• 增長了自動填充源、目標分支的功能；
• 支持評審人推薦，基於代碼庫的歷史操做，將最熟悉你改動代碼的庫成員推薦爲評審人，讓你方便的選擇最適合的評審者；
• 針對老是須要重複選擇評審人的問題，保護分支支持設置默認評審人，減小冗餘手工操做。若是你有按目錄設置評審人的強大意願，還可使用CodeOwner模式（好比A目錄讓甲同窗負責，B目錄下的文件由乙同窗負責），設置後會將對應目錄的代碼負責人自動加爲評審人。

2.下降人力投入評審的人力投入是最大的成本，隨着自動化掃描能力的增長，人工評審前的機器預評審成爲了主流。

雲效Codeup 提供了代碼掃描能力，守護代碼安全和質量。內置的代碼掃描包括【代碼規約掃描】、【依賴包漏洞掃描】、【敏感信息掃描】、【補丁推薦掃描】，也能夠基於雲效的 Flow（流水線）配置單元測試和自定義掃描節點，例如【源碼漏洞檢測】、PHP/Python/Go 等常見語言的代碼掃描，再將結果關聯到評審上。

對於比較簡單的評審，自動化測試的保障已經足夠，大大減小了人力和時間投入成本，同時也防控了缺陷的引入。

3.優化評審流程體驗網頁端對於瀏覽簡單邏輯的代碼很是方便，可是若是存在較多互相引用的函數調用，閱讀起來就比較費力了。雲效Codeup 針對評審複雜狀況，支持了網頁端的函數引用快速跳轉（咱們稱爲智能語法服務），避免在網頁上艱難的切換文件視圖；對於習慣本地IDE看代碼的同窗，雲效Codeup 也支持了IDEA的代碼評審插件，不用來回切換編輯器和網頁，直接在IDEA裏面就能夠進行代碼評審，甚至一鍵合併代碼，很是方便。

另外，一般一個特性可能須要多人協做開發，爲了減小合併代碼時的衝突，雲效Codeup 提供了衝突預檢測的能力，支持經過網頁端的 WebIDE 自動解決衝突並快速提交。

在評審協做通知方面，評審的關鍵動態支持經過站內信、郵件、釘釘的方式及時通知到評審參與方，避免你等我我等你的尷尬，可以更高效的推動評審的進度，更快一步完成迭代。

4.支持查看評審活動狀況Codeup 針對評審活動，提供了單獨的度量報表，能夠看到倉庫內每次提交是否通過了評審，查看提交和代碼行的評審率，每一個倉庫成員的評審活動參與次數，收到評審邀約的響應速度，若是有同窗評審老是拖延，可能他就是迭代的一個阻塞點，也許應該爲他減輕工做或者選擇其餘評審人幫助補位；

在評審活動中，咱們也是鼓勵評論的，有問題說出來，不管是疑問仍是誇讚，也方便後續的回顧追溯。此外，千行代碼評論數也能夠做爲管理者對評審有效性評估的可視化度量參考。

做者：Yvonne原文連接本文爲阿里雲原創內容，未經容許不得轉載