评审恩仇录——我为什么愿意执行代码评审
難得請(qǐng)了年假,躺在陽光海浪仙人掌的沙灘上喝著椰汁,突然接到系統(tǒng)報(bào)警電話,立刻跳起來抱著電腦到處找WIFI的場(chǎng)景是否似曾相識(shí)。
身為技術(shù)開發(fā),每逢放假恨不得燒香祈愿線上穩(wěn)定,如果能夠在問題引入前提前扼制風(fēng)險(xiǎn),就可以放心享受悠閑的假期了。
而代碼評(píng)審,就是扼制風(fēng)險(xiǎn)的有效手段之一。
代碼評(píng)審帶來的好處不言自明, 但企業(yè)業(yè)務(wù)快速發(fā)展的訴求與代碼評(píng)審?fù)苿?dòng)落地兩者之間, 往往存在矛盾。在如今快速發(fā)展的互聯(lián)網(wǎng)時(shí)代,數(shù)字化、智能化已經(jīng)是基礎(chǔ)能力,單純只靠人肉審查的時(shí)代已經(jīng)過去了,基于各種自動(dòng)化檢查能力的加持,其實(shí)代碼評(píng)審并沒有想象中那么費(fèi)時(shí)費(fèi)力。今天和大家聊一聊在快節(jié)奏的業(yè)務(wù)現(xiàn)狀下基于云效代碼管理產(chǎn)品云效Codeup如何更低成本的開展代碼評(píng)審。
話題開始之前,先簡單介紹下代碼評(píng)審的概念。
代碼評(píng)審,英文名是Code Review,簡稱CR,它是結(jié)對(duì)編程相互切磋相互學(xué)習(xí)的方式。一定頻次的CR能夠提升咱們的代碼質(zhì)量、促進(jìn)人才成長。
一、提升代碼質(zhì)量
所謂代碼質(zhì)量,可以從兩個(gè)維度來理解,一是可讀性,二是減少缺陷。
- 可讀性:Code Review 機(jī)制的誕生最早是為了保證代碼具有良好的可讀性。代碼是一種資產(chǎn),并且具有“流通性”,通常會(huì)需要多年的維護(hù),并且面臨維護(hù)人員更替的情況,誰都不希望自己接手的是一份“天書”一樣的代碼。使用CR的敏捷團(tuán)隊(duì)更是能獲得巨大的好處,因?yàn)閳F(tuán)隊(duì)的工作是分散的,通過代碼評(píng)審可以讓團(tuán)隊(duì)所有人都能夠有機(jī)會(huì)了解對(duì)方的代碼內(nèi)容,有助于促進(jìn)跨庫和整個(gè)團(tuán)隊(duì)的知識(shí)共享,讓任何團(tuán)隊(duì)成員都可以接管并繼續(xù)推進(jìn)整個(gè)工程的演進(jìn)。
- 減少缺陷:Code Review 能夠發(fā)現(xiàn)除程序邏輯以外的設(shè)計(jì)、性能、安全、規(guī)范等多方面的問題。在這個(gè)過程中,除了依賴評(píng)審人的專業(yè)能力外,也給了我們更多讓自動(dòng)化和智能化檢測(cè)手段介入的機(jī)會(huì),包括對(duì)代碼規(guī)范和安全的自動(dòng)化檢查、基于AI的缺陷分析和補(bǔ)丁推薦、合并的風(fēng)險(xiǎn)評(píng)估等。
二、促進(jìn)人才成長
很多團(tuán)隊(duì)都由擁有不同經(jīng)驗(yàn)的成員組成,代碼評(píng)審是一個(gè)互相檢查錯(cuò)誤,互相學(xué)習(xí)代碼的機(jī)會(huì)。如果團(tuán)隊(duì)的技術(shù)骨干人員,能參與到團(tuán)隊(duì)日常的架構(gòu)評(píng)審、設(shè)計(jì)評(píng)審以及代碼評(píng)審中,除了能夠降低出錯(cuò)率,減少設(shè)計(jì)初期的風(fēng)險(xiǎn)故障外,還可以切切實(shí)實(shí)的幫助到其他研發(fā)人員的成長。體感更明顯的團(tuán)隊(duì)會(huì)發(fā)現(xiàn)團(tuán)隊(duì)的開發(fā)質(zhì)量在逐漸提高,并且不斷在向團(tuán)隊(duì)最高水平成員靠攏。
三、兩種評(píng)審場(chǎng)景
我們可以基于評(píng)審過程的嚴(yán)格程度,把評(píng)審分為輕/重兩類,可以根據(jù)自身業(yè)務(wù)情況選擇最合適的評(píng)審方式。
1.輕評(píng)審很多企業(yè)管理者會(huì)覺得評(píng)審會(huì)耽誤業(yè)務(wù)的迭代速度,評(píng)審和速度是魚與熊掌不可兼得的事,當(dāng)然業(yè)務(wù)最重要,評(píng)審就被自然舍棄了。
對(duì)于看重迭代速度的企業(yè),輕評(píng)審是一個(gè)不錯(cuò)的選擇,它沒有強(qiáng)制的規(guī)則卡點(diǎn),不要求評(píng)審人必須嚴(yán)格的閱讀每一行代碼給出評(píng)審意見,結(jié)合自動(dòng)化檢測(cè)的能力,在代碼合并入重要分支的時(shí)候做一次安全和質(zhì)量掃描,人力投入可控,可以更加靈活的根據(jù)當(dāng)前業(yè)務(wù)狀況決定是否立即合并代碼,可以小成本的完成評(píng)審。
2.重評(píng)審
而對(duì)于一些流程嚴(yán)格,或上線代碼安全質(zhì)量要求高的公司,從管理層就要求一系列評(píng)審的硬性卡點(diǎn),包括自動(dòng)化檢查、必須通過的評(píng)審人數(shù)、評(píng)論解決狀態(tài)等等,其中任何一條不滿足都不允許合并,這種情況就需要使用重評(píng)審特性的一系列管控能力了。
還有一些企業(yè),不僅對(duì)保護(hù)分支的合入強(qiáng)制管控,甚至對(duì)每一次提交都有要求,希望任何推送到服務(wù)端的代碼都要經(jīng)過評(píng)審,這種場(chǎng)景對(duì)評(píng)審的要求非常高,而Codeup創(chuàng)新的集中式工作流 Agit-Flow 可以很好的解決這個(gè)場(chǎng)景。
接下來我們先看下常規(guī)的評(píng)審流程是什么樣子的:
四、常規(guī)評(píng)審流程
代碼評(píng)審主要分為三個(gè)階段:評(píng)審開始、評(píng)審中和評(píng)審結(jié)束。
常規(guī)流程中各個(gè)階段存在的主要困難有:
- 評(píng)審開始階段,對(duì)于發(fā)起人,需要從大量庫成員中選擇合適的評(píng)審人,填寫必要信息完成評(píng)審創(chuàng)建,并通知評(píng)審人及時(shí)前來評(píng)審。而對(duì)于評(píng)審人,通常會(huì)存在多個(gè)評(píng)審邀請(qǐng),需要安排工作的間隙選擇適合的評(píng)審各個(gè)擊破或者用固定的時(shí)段集中評(píng)審。評(píng)審人點(diǎn)開評(píng)審,依次瀏覽代碼邏輯,對(duì)于比較復(fù)雜的嵌套或調(diào)用依賴,還需要去本地IDE查看內(nèi)部邏輯;
- 評(píng)審過程中,負(fù)責(zé)的評(píng)審人會(huì)基于漏洞,風(fēng)格,缺陷等維度提出評(píng)論。要等待評(píng)審發(fā)起人收到通知后修復(fù)代碼,然后提交再次評(píng)審。如此迭代,直到問題被解決,評(píng)審人點(diǎn)擊通過評(píng)審,如果源分支和目標(biāo)分支有代碼沖突的話,需要評(píng)審發(fā)起人去解決沖突,最后合并代碼。
常規(guī)的代碼評(píng)審流程主要有以下問題:
1.創(chuàng)建評(píng)審麻煩:評(píng)審的創(chuàng)建需要手動(dòng)填寫大量信息,很多操作是重復(fù)勞動(dòng)或是無從下手的;
2.人力投入成本高:最傳統(tǒng)的代碼評(píng)審是結(jié)對(duì)編程,以及團(tuán)隊(duì)圓桌評(píng)審,人力的投入顯而易見。代碼評(píng)審轉(zhuǎn)移到線上后,仍然需要多人仔細(xì)校對(duì)、分析和線下討論。缺少自動(dòng)化評(píng)審手段是關(guān)鍵。
3.評(píng)審流程體驗(yàn)差:評(píng)審過程中純文本的代碼難以展現(xiàn)代碼的深刻邏輯,代碼是立體的,部分改動(dòng)的方法需要去查看定義和引用才能看出問題,否則只能是蜻蜓點(diǎn)水,效果有限,負(fù)責(zé)的評(píng)審人往往需要結(jié)合本地IDE來配合使用。評(píng)審發(fā)起人收到評(píng)論后,需要去本地修改提交后,再回復(fù)評(píng)論,路徑很長。評(píng)審的通過、合并也沒有卡點(diǎn)規(guī)則,任何有權(quán)限的人都能做這些操作,卻可能會(huì)忽略評(píng)審的問題沒有解決,導(dǎo)致本可以提前解決的問題帶入線上生產(chǎn)環(huán)境。
4.評(píng)審活動(dòng)情況難評(píng)估:管理者常常希望能夠衡量,團(tuán)隊(duì)的成員是否真正踐行評(píng)審,保證評(píng)審質(zhì)量,而不是隨意通過評(píng)審,只是走個(gè)流程。
五、云效智能代碼評(píng)審
針對(duì)常規(guī)代碼評(píng)審存在的問題,云效Codeup 通過智能算法和流程管控能力,讓評(píng)審更加高效。
1.提升創(chuàng)建速度創(chuàng)建評(píng)審需要填寫一堆基礎(chǔ)信息,云效Codeup 努力將用戶需要輸入的內(nèi)容壓縮到最少:
- 增加了自動(dòng)填充源、目標(biāo)分支的功能;
- 支持評(píng)審人推薦,基于代碼庫的歷史操作,將最熟悉你改動(dòng)代碼的庫成員推薦為評(píng)審人,讓你方便的選擇最適合的評(píng)審者;
- 針對(duì)總是需要重復(fù)選擇評(píng)審人的問題,保護(hù)分支支持設(shè)置默認(rèn)評(píng)審人,減少冗余手工操作。如果你有按目錄設(shè)置評(píng)審人的強(qiáng)大意愿,還可以使用CodeOwner模式(比如A目錄讓甲同學(xué)負(fù)責(zé),B目錄下的文件由乙同學(xué)負(fù)責(zé)),設(shè)置后會(huì)將對(duì)應(yīng)目錄的代碼負(fù)責(zé)人自動(dòng)加為評(píng)審人。
2.降低人力投入評(píng)審的人力投入是最大的成本,隨著自動(dòng)化掃描能力的增加,人工評(píng)審前的機(jī)器預(yù)評(píng)審成為了主流。
云效Codeup 提供了代碼掃描能力,守護(hù)代碼安全和質(zhì)量。內(nèi)置的代碼掃描包括【代碼規(guī)約掃描】、【依賴包漏洞掃描】、【敏感信息掃描】、【補(bǔ)丁推薦掃描】,也可以基于云效的 Flow(流水線)配置單元測(cè)試和自定義掃描節(jié)點(diǎn),例如【源碼漏洞檢測(cè)】、PHP/Python/Go 等常見語言的代碼掃描,再將結(jié)果關(guān)聯(lián)到評(píng)審上。
對(duì)于比較簡單的評(píng)審,自動(dòng)化測(cè)試的保障已經(jīng)足夠,大大減少了人力和時(shí)間投入成本,同時(shí)也防控了缺陷的引入。
3.優(yōu)化評(píng)審流程體驗(yàn)網(wǎng)頁端對(duì)于瀏覽簡單邏輯的代碼非常方便,但是如果存在較多互相引用的函數(shù)調(diào)用,閱讀起來就比較費(fèi)力了。云效Codeup 針對(duì)評(píng)審復(fù)雜情況,支持了網(wǎng)頁端的函數(shù)引用快速跳轉(zhuǎn)(我們稱為智能語法服務(wù)),避免在網(wǎng)頁上艱難的切換文件視圖;對(duì)于習(xí)慣本地IDE看代碼的同學(xué),云效Codeup 也支持了IDEA的代碼評(píng)審插件,不用來回切換編輯器和網(wǎng)頁,直接在IDEA里面就可以進(jìn)行代碼評(píng)審,甚至一鍵合并代碼,非常方便。
另外,通常一個(gè)特性可能需要多人協(xié)作開發(fā),為了減少合并代碼時(shí)的沖突,云效Codeup 提供了沖突預(yù)檢測(cè)的能力,支持通過網(wǎng)頁端的 WebIDE 自動(dòng)解決沖突并快速提交。
在評(píng)審協(xié)作通知方面,評(píng)審的關(guān)鍵動(dòng)態(tài)支持通過站內(nèi)信、郵件、釘釘?shù)姆绞郊皶r(shí)通知到評(píng)審參與方,避免你等我我等你的尷尬,能夠更高效的推進(jìn)評(píng)審的進(jìn)度,更快一步完成迭代。
4.支持查看評(píng)審活動(dòng)情況Codeup 針對(duì)評(píng)審活動(dòng),提供了單獨(dú)的度量報(bào)表,可以看到倉庫內(nèi)每次提交是否經(jīng)過了評(píng)審,查看提交和代碼行的評(píng)審率,每個(gè)倉庫成員的評(píng)審活動(dòng)參與次數(shù),收到評(píng)審邀約的響應(yīng)速度,如果有同學(xué)評(píng)審總是拖延,可能他就是迭代的一個(gè)阻塞點(diǎn),也許應(yīng)該為他減輕工作或者選擇其他評(píng)審人幫助補(bǔ)位;
在評(píng)審活動(dòng)中,我們也是鼓勵(lì)評(píng)論的,有問題說出來,無論是疑問還是夸贊,也方便后續(xù)的回顧追溯。此外,千行代碼評(píng)論數(shù)也可以作為管理者對(duì)評(píng)審有效性評(píng)估的可視化度量參考。
說了這么多,你現(xiàn)在還覺得代碼評(píng)審會(huì)是業(yè)務(wù)飛馳的絆腳石嗎?好的理念要付出實(shí)踐,快去試試吧!
更多小提示
了解 Agit-Flow 阿里巴巴集中式工作流,讓創(chuàng)建代碼評(píng)審像提交一樣簡單:http://t.tb.cn/36VCKdTVaMGVfKFMLFcyuo
原文鏈接:https://developer.aliyun.com/article/782685?
版權(quán)聲明:本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn),版權(quán)歸原作者所有,阿里云開發(fā)者社區(qū)不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容,填寫侵權(quán)投訴表單進(jìn)行舉報(bào),一經(jīng)查實(shí),本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的评审恩仇录——我为什么愿意执行代码评审的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 三只松鼠:阿里云数据中台基座上的多渠道、
- 下一篇: 阿里云 OpenAPI 开发者门户全新上