评审恩仇录——我为什么愿意执行代码评审
難得請了年假，躺在陽光海浪仙人掌的沙灘上喝著椰汁，突然接到系統報警電話，立刻跳起來抱著電腦到處找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里面就可以進行代碼評審，甚至一鍵合并代碼，非常方便。
另外，通常一個特性可能需要多人協作開發，為了減少合并代碼時的沖突，云效Codeup 提供了沖突預檢測的能力，支持通過網頁端的 WebIDE 自動解決沖突并快速提交。
在評審協作通知方面，評審的關鍵動態支持通過站內信、郵件、釘釘的方式及時通知到評審參與方，避免你等我我等你的尷尬，能夠更高效的推進評審的進度，更快一步完成迭代。
4.支持查看評審活動情況Codeup 針對評審活動，提供了單獨的度量報表，可以看到倉庫內每次提交是否經過了評審，查看提交和代碼行的評審率，每個倉庫成員的評審活動參與次數，收到評審邀約的響應速度，如果有同學評審總是拖延，可能他就是迭代的一個阻塞點，也許應該為他減輕工作或者選擇其他評審人幫助補位；
在評審活動中，我們也是鼓勵評論的，有問題說出來，無論是疑問還是夸贊，也方便后續的回顧追溯。此外，千行代碼評論數也可以作為管理者對評審有效性評估的可視化度量參考。
說了這么多，你現在還覺得代碼評審會是業務飛馳的絆腳石嗎？好的理念要付出實踐，快去試試吧！
更多小提示
了解 Agit-Flow 阿里巴巴集中式工作流，讓創建代碼評審像提交一樣簡單：http://t.tb.cn/36VCKdTVaMGVfKFMLFcyuo
原文鏈接：https://developer.aliyun.com/article/782685?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的评审恩仇录——我为什么愿意执行代码评审的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 三只松鼠：阿里云数据中台基座上的多渠道、
- 下一篇： 阿里云 OpenAPI 开发者门户全新上