評審恩仇錄——我為什麼願意執行代碼評審詳情 - 前端,react,bootstrap,coffeescript 數據庫知識分享者博客

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

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

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

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

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

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

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

一、提升代碼質量

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

可讀性：Code Review 機制的誕生最早是為了保證代碼具有良好的可讀性。代碼是一種資產，並且具有“流通性”，通常會需要多年的維護，並且面臨維護人員更替的情況，誰都不希望自己接手的是一份“天書”一樣的代碼。使用CR的敏捷團隊更是能獲得巨大的好處，因為團隊的工作是分散的，通過代碼評審可以讓團隊所有人都能夠有機會了解對方的代碼內容，有助於促進跨庫和整個團隊的知識共享，讓任何團隊成員都可以接管並繼續推進整個工程的演進。
減少缺陷：Code Review 能夠發現除程序邏輯以外的設計、性能、安全、規範等多方面的問題。在這個過程中，除了依賴評審人的專業能力外，也給了我們更多讓自動化和智能化檢測手段介入的機會，包括對代碼規範和安全的自動化檢查、基於AI的缺陷分析和補丁推薦、合併的風險評估等。

二、促進人才成長

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

三、兩種評審場景

我們可以基於評審過程的嚴格程度，把評審分為輕/重兩類，可以根據自身業務情況選擇最合適的評審方式。

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

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

2.重評審

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

還有一些企業，不僅對保護分支的合入強制管控，甚至對每一次提交都有要求，希望任何推送到服務端的代碼都要經過評審，這種場景對評審的要求非常高，而Codeup創新的集中式工作流 Agit-Flow 可以很好的解決這個場景。

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

四、常規評審流程

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

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

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

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

1.創建評審麻煩：評審的創建需要手動填寫大量信息，很多操作是重複勞動或是無從下手的；

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

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

4.評審活動情況難評估：管理者常常希望能夠衡量，團隊的成員是否真正踐行評審，保證評審質量，而不是隨意通過評審，只是走個流程。

五、雲效智能代碼評審

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

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

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

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

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

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

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