【以下為分享實(shí)錄，有刪節(jié)】

阿里巴巴為什么要自研代碼管理平臺(tái)

也許你會(huì)問(wèn)：為什么阿里巴巴要重新做一套代碼管理平臺(tái)，繼續(xù)用Gitlab版本不是挺好的嗎？接下來(lái)從我個(gè)人的角度在這里嘗試進(jìn)行解答。

由于歷史原因，在阿里巴巴集團(tuán)內(nèi)部代碼平臺(tái)是整個(gè)DevOps領(lǐng)域中起步相對(duì)較晚的一塊業(yè)務(wù)域，相比于發(fā)布域、測(cè)試域有著多年的積累和沉淀來(lái)講，2017年時(shí)的代碼平臺(tái)可以說(shuō)是為了滿足整體業(yè)務(wù)需求由幾個(gè)系統(tǒng)強(qiáng)行拼湊起來(lái)的。

為了支撐起阿里巴巴整體的業(yè)務(wù)發(fā)展，研發(fā)團(tuán)隊(duì)要同時(shí)維護(hù)6個(gè)系統(tǒng)，分別是負(fù)責(zé)代碼托管的GitLab、Svn、Gerrit，以及負(fù)責(zé)上層代碼服務(wù)的Phabricator、CodeCenter、ScmCenter。且其中除了CodeCenter、ScmCenter之外，其它四個(gè)均是在開(kāi)源系統(tǒng)之上二次封裝改造而來(lái)的。其中Gitlab技術(shù)棧是基于Ruby，Phabricator基于PHP，SVN基于C，Gerrit基于Java,這給我們?nèi)粘５拈_(kāi)發(fā)和維護(hù)工作增加了很多負(fù)擔(dān)。

當(dāng)時(shí)代碼平臺(tái)遇到的困難和挑戰(zhàn)主要有四個(gè)方面：

一、技術(shù)架構(gòu)方面：多套系統(tǒng)架構(gòu)，多種開(kāi)發(fā)語(yǔ)言，不僅維護(hù)成本高，且與阿里集團(tuán)的主流技術(shù)脫節(jié)，研發(fā)團(tuán)隊(duì)同學(xué)每天疲于填坑，然而整體上卻得不到大的改善。

二、平臺(tái)發(fā)展方面：?jiǎn)渭兊腉itlab、Svn、Gerrit均無(wú)法與周邊關(guān)聯(lián)系統(tǒng)做到有效協(xié)同，且用戶的多樣性需求也很難在某個(gè)單一系統(tǒng)中得到滿足，最關(guān)鍵的一點(diǎn)是我們雖然手握海量代碼資產(chǎn)，但其寶貴價(jià)值卻未有效挖掘出來(lái)。

三、外部市場(chǎng)方面：代碼托管領(lǐng)域的市場(chǎng)是很有發(fā)展?jié)摿Φ?，但?guó)內(nèi)還沒(méi)有一款真正To B形態(tài)的代碼管理平臺(tái)。這是因?yàn)閷?duì)于科技企業(yè)來(lái)講，代碼是最核心的資產(chǎn)，企業(yè)把代碼托管到誰(shuí)的平臺(tái)就等于把身家性命托付給了誰(shuí)。因此一款To B形態(tài)的代碼管理平臺(tái)必須具備豐富的企業(yè)級(jí)特性以及完備的安全能力，然而在這一方面國(guó)內(nèi)代碼托管產(chǎn)品還有很長(zhǎng)的路要走。

同時(shí)這也是“自主可控”的需要。作為托管代碼的基礎(chǔ)平臺(tái)進(jìn)行國(guó)產(chǎn)化既是大勢(shì)所趨也是時(shí)代所需。只有將核心技術(shù)和產(chǎn)品把控在我們中國(guó)人自己手里才能從容面對(duì)未來(lái)各種不確定性。

四、代碼文化方面：即如何正向推動(dòng)阿里巴巴的代碼文化傳承。

阿里巴巴代碼管理平臺(tái)的整體策略

針對(duì)于以上代碼平臺(tái)所面臨的四個(gè)方面的問(wèn)題和挑戰(zhàn)，該如何去解決，我們的整體思考和策略如下：

第一、統(tǒng)一架構(gòu)，夯實(shí)基礎(chǔ)：必須要統(tǒng)一架構(gòu)，不能再在開(kāi)源系統(tǒng)上拼拼湊湊，需要有一套完全能自主掌控的自研系統(tǒng)，從頭夯實(shí)好基礎(chǔ)。

第二、全面融合，高效協(xié)同：需要解決6套老系統(tǒng)如何與該自研系統(tǒng)過(guò)渡，同時(shí)該系統(tǒng)應(yīng)該與DevOps領(lǐng)域中其它上下游系統(tǒng)能夠方便的打通、協(xié)同。

第三，代碼文化，品牌建設(shè)：在代碼平臺(tái)建設(shè)的同時(shí)，要考慮如何對(duì)阿里巴巴的代碼文化和理念進(jìn)行正向引導(dǎo)，從而做到以工具和平臺(tái)作為載體，使代碼文化進(jìn)行有效落地。同時(shí)還要進(jìn)行我們自己產(chǎn)品的品牌建設(shè)。

第四，擁抱智能，彎道超車：面對(duì)競(jìng)品我們?nèi)绾尾拍苷嬲摲f而出、打出差異性，答案就是擁抱智能，通過(guò)智能化的手段進(jìn)行彎道超車。

基于以上策略，我們開(kāi)始了自研之路，全新的代碼管理平臺(tái)先是在阿里巴巴集團(tuán)內(nèi)部進(jìn)行落地，進(jìn)而解決了前文中提到的四個(gè)方面的問(wèn)題。

經(jīng)過(guò)充足的準(zhǔn)備，我們將這款自研代碼管理平臺(tái)集成到云效中，成為了“云效代碼管理平臺(tái)”，即Codeup，目前開(kāi)發(fā)者可從云效官網(wǎng)訪問(wèn)并免費(fèi)使用。“云效代碼管理”（Codeup）是一款企業(yè)級(jí)代碼管理平臺(tái)，提供代碼托管、代碼評(píng)審、代碼掃描、質(zhì)量檢測(cè)等功能，保護(hù)企業(yè)代碼資產(chǎn)，實(shí)現(xiàn)安全、穩(wěn)定、高效的研發(fā)生產(chǎn)。拋開(kāi)產(chǎn)品設(shè)計(jì)或團(tuán)隊(duì)打造這些方面，我們?cè)诩夹g(shù)上究竟是如何做的，這個(gè)我會(huì)在后面進(jìn)行詳細(xì)介紹。

云效代碼管理平臺(tái)的核心能力

云效代碼管理（Codeup）主要提供代碼瀏覽、代碼評(píng)審、配置管理（SCM）、代碼掃描、代碼安全、CI/CD、文檔、代碼庫(kù)遷移等能力和服務(wù)。

很多企業(yè)的技術(shù)負(fù)責(zé)人也許會(huì)糾結(jié)一個(gè)問(wèn)題：將代碼托管到云上是否安全？

一些企業(yè)在最終進(jìn)行代碼托管時(shí)，均會(huì)選擇自己搭建代碼托管系統(tǒng)，其實(shí)阿里早期也是如此，因此我們深知其中利弊。自己搭建代碼托管系統(tǒng)，就需要做以下相關(guān)工作：首先，需要選擇適合企業(yè)代碼托管場(chǎng)景的開(kāi)源軟件；其次，準(zhǔn)備托管的硬件設(shè)施。在此過(guò)程中，必須滿足一些特定的要求，如需要對(duì)開(kāi)源軟件比較熟悉的技術(shù)人員進(jìn)行搭建與維護(hù)；需要花費(fèi)成本去購(gòu)買實(shí)體或云端服務(wù)器；同時(shí)需要投入人力來(lái)負(fù)責(zé)安全及穩(wěn)定性，否則就可能因?yàn)橄到y(tǒng)的穩(wěn)定性而影響研發(fā)效率。

如果采用成熟的云端代碼托管平臺(tái)，就可以很好的避免上述問(wèn)題。以云效代碼管理平臺(tái)（Codeup）為例，在代碼存儲(chǔ)方面，我們采用多副本高可用架構(gòu)，數(shù)據(jù)自動(dòng)備份；在代碼安全方面，我們提供完善的安全權(quán)限機(jī)制和保護(hù)措施，降低內(nèi)部成員泄露代碼數(shù)據(jù)和外部黑客攻擊的風(fēng)險(xiǎn)。

綜合來(lái)看，對(duì)于中小企業(yè)及大型企業(yè)的開(kāi)發(fā)人員，選擇成熟的云端代碼托管平臺(tái)，是更安全更省心更經(jīng)濟(jì)的選擇。

云效代碼管理平臺(tái)的系統(tǒng)架構(gòu)

早些年，阿里巴巴集團(tuán)內(nèi)部采用的是AliGitLab系統(tǒng)架構(gòu)，雖然在Gitlab上進(jìn)行了分布式的改造，使這套系統(tǒng)的承載能力得到很大的提升。但是AliGitLab在架構(gòu)上仍然屬于單層分片架構(gòu)，因?yàn)閃eb服務(wù)和Git托管這兩個(gè)核心組件其實(shí)是部署在同一臺(tái)機(jī)器上的，耦合十分嚴(yán)重，擴(kuò)展能力非常差，且整個(gè)服務(wù)模塊都是基于Ruby技術(shù)棧。這就使整個(gè)架構(gòu)存在兩個(gè)弊端：一是整個(gè)體系基于Ruby，導(dǎo)致維護(hù)、擴(kuò)展以及人員培養(yǎng)成本都很大；二是Web服務(wù)和Git托管耦合在一起，很多情況下會(huì)因?yàn)槟硞€(gè)節(jié)點(diǎn)上代碼庫(kù)讀寫占用大量資源而對(duì)用戶在該節(jié)點(diǎn)上的頁(yè)面訪問(wèn)或API服務(wù)請(qǐng)求造成影響。

針對(duì)上述問(wèn)題，我們?cè)谠菩Тa管理平臺(tái)（Codeup）上實(shí)現(xiàn)了全新的架構(gòu)。通過(guò)明確的抽象、分層，將Codeup整體劃分為三層，即由下至上為存儲(chǔ)層、代理層和服務(wù)層。同時(shí)抽取出5個(gè)系統(tǒng)核心組件，服務(wù)組件間彼此職責(zé)單一、分離，上層Service和Portal基于Java進(jìn)行實(shí)現(xiàn)，無(wú)狀態(tài)；存儲(chǔ)層及代理層組件全部用Go語(yǔ)言編寫。Codeup-stone主要負(fù)責(zé)文件存儲(chǔ)及底層Git操作的封裝，其上抽取一個(gè)中間代理層，各層之間基于GRPC協(xié)議進(jìn)行高效的數(shù)據(jù)傳輸。服務(wù)層的各項(xiàng)請(qǐng)求都基于Codeup-Proxy去與存儲(chǔ)層打交道，從整體上大幅增強(qiáng)了系統(tǒng)的容災(zāi)能力和擴(kuò)展性，每一層都可以做到方便的擴(kuò)容、縮容。這套自研系統(tǒng)架構(gòu)經(jīng)過(guò)多年打磨和演進(jìn)，在阿里巴巴集團(tuán)內(nèi)部承載起了數(shù)萬(wàn)工程師，上百系統(tǒng)的大規(guī)模、高并發(fā)的日常調(diào)用壓力。

在開(kāi)發(fā)者最關(guān)心的穩(wěn)定性和文件存儲(chǔ)方面，我們采用了多節(jié)點(diǎn)“分片”和單節(jié)點(diǎn)“一主多備”以及跨機(jī)房“冷備”的手段，來(lái)保障數(shù)據(jù)的高安全和高可靠性。同時(shí)云效代碼管理平臺(tái)（Codeup）全部組件均架構(gòu)在阿里云基礎(chǔ)設(shè)施之上，以此來(lái)確保存儲(chǔ)、應(yīng)用服務(wù)器、網(wǎng)絡(luò)等硬件方面的安全穩(wěn)定。

在數(shù)據(jù)存儲(chǔ)和高可用方面，我們具體采取了以下三點(diǎn)措施：一、在底層存儲(chǔ)節(jié)點(diǎn)上，對(duì)代碼庫(kù)進(jìn)行哈希散列處理，從而避免存儲(chǔ)節(jié)點(diǎn)因?yàn)閭}(cāng)庫(kù)分布不均勻而成為“熱點(diǎn)”；二、針對(duì)單個(gè)節(jié)點(diǎn)可能因?yàn)榇鎯?chǔ)“大庫(kù)”而成為“熱點(diǎn)”的問(wèn)題，Codeup通過(guò)多副本的方式對(duì)單個(gè)節(jié)點(diǎn)的請(qǐng)求進(jìn)行負(fù)載均衡，根據(jù)實(shí)際流量，可以進(jìn)行快速的擴(kuò)容或縮容；三、在倉(cāng)庫(kù)數(shù)據(jù)備份方面，我們采取了多份熱備份和一份冷備份的方案。其中，熱備份至少會(huì)存在兩份，冷備份存儲(chǔ)全量的數(shù)據(jù)快照。針對(duì)用戶由于誤操作產(chǎn)生的數(shù)據(jù)刪除等不可逆的問(wèn)題時(shí)，我們可以通過(guò)冷備份的數(shù)據(jù)快照進(jìn)行恢復(fù)。目前快照數(shù)據(jù)保存的周期為一周。

除了基礎(chǔ)架構(gòu)，我們?cè)诖a智能化、代碼規(guī)范化等方面也做了大量的投入。基于阿里巴巴集團(tuán)內(nèi)部海量的代碼數(shù)據(jù)，在代碼安全、代碼質(zhì)量和研發(fā)提效等方面的我們都進(jìn)行了大量探索和創(chuàng)新。這次也是希望借助我們自研的云效代碼管理平臺(tái)（Codeup）將這些優(yōu)秀的能力開(kāi)放出去，普惠更多中小企業(yè)。接下來(lái)，我會(huì)針對(duì)Codeup上代表性的功能和工具進(jìn)行詳細(xì)介紹。

人工智能技術(shù)助力敏感信息監(jiān)測(cè)

首先，我們來(lái)了解一下云效代碼管理平臺(tái)（Codeup）在企業(yè)智能安全方面的功能。我們?yōu)槠髽I(yè)管理者提供了安全風(fēng)控、審計(jì)日志、IP白名單等把控代碼庫(kù)安全的核心能力。今天主要介紹一下敏感行為監(jiān)測(cè)，我們是如何做的。

首先，我們以代碼數(shù)倉(cāng)為基礎(chǔ)構(gòu)建了代碼圖譜，通過(guò)對(duì)代碼庫(kù)、代碼、工程師進(jìn)行抽象將其轉(zhuǎn)化為實(shí)體，并通過(guò)實(shí)體的標(biāo)簽化構(gòu)建代碼畫像、用戶畫像等。為智能服務(wù)提供有力的數(shù)據(jù)支持，為平臺(tái)業(yè)務(wù)提供推理關(guān)系查詢。在敏感行為檢測(cè)這個(gè)例子中，我們提取出了代碼庫(kù)重要度、文件重要度、代碼段重要度、開(kāi)發(fā)人員近期瀏覽行為、開(kāi)發(fā)人員畫像作為安全防護(hù)的支撐內(nèi)容。一旦有重要庫(kù)、重要文件發(fā)生敏感操作，如突然的大量代碼庫(kù)下載、刪庫(kù)、權(quán)限變更等行為，我們會(huì)立刻給訂閱用戶發(fā)送通知告警，幫助企業(yè)管理者感知風(fēng)險(xiǎn)，及時(shí)止損。

代碼質(zhì)量—飽受好評(píng)的P3C代碼規(guī)約檢測(cè)插件

在代碼質(zhì)量方面，云效代碼管理平臺(tái)（Codeup）內(nèi)置了我們自研的P3C代碼規(guī)劃?rùn)z測(cè)插件。這款插件在阿里巴巴內(nèi)部飽受好評(píng)，使用廣泛；目前已經(jīng)開(kāi)源，在業(yè)界也很受歡迎，無(wú)論是插件的下載量，還是在Github源碼工程上的加星數(shù)都很高。 那么，P3C技術(shù)上是如何實(shí)現(xiàn)的呢?

經(jīng)過(guò)多次調(diào)研和探討，我們選擇了開(kāi)源代碼掃描工具PMD去做資源與規(guī)則擴(kuò)展，主要是看中了其規(guī)則擴(kuò)展方便，集成到其它通用平臺(tái)和插件上更靈活的特性。但PMD也有其局限性，即不支持跨文件掃描（例如：對(duì)過(guò)時(shí)方法的檢測(cè)），所以那些需要針對(duì)跨文件掃描的規(guī)則我們提到了Sonar、IDE等上層工具去實(shí)現(xiàn)。

• 方案選定后，我們基于開(kāi)源的pmd-core三方Jar的能力上，擴(kuò)展了約60個(gè)規(guī)約掃描規(guī)則，并封裝出P3C-PMD組件。
• 在P3C-PMD組件基礎(chǔ)上，基于Sonar插件擴(kuò)展標(biāo)準(zhǔn)，我們提供了sonar-p3c-pmd-plugin，也就是封裝出了一個(gè)標(biāo)準(zhǔn)的Sonar插件。此插件主要用于代碼庫(kù)全量自動(dòng)化掃描階段。
• CodeReview插件采用直接類似于命令行調(diào)用的方式集成了p3c-pmd，主要針對(duì)于增量代碼檢測(cè)階段。
• 在P3C-PMD組件基礎(chǔ)上，基于IDEA的Inspection機(jī)制，以及Running Inspection By Name的功能自主實(shí)現(xiàn)了IDEA插件。
• Eclipse插件主要是基于原生已有的Eclipse PMD插件進(jìn)行的規(guī)則替換開(kāi)發(fā)。我們通過(guò)IDE插件的實(shí)現(xiàn)，進(jìn)而解決了本地代碼規(guī)約檢測(cè)的問(wèn)題。

綜上所述，我們通過(guò)不同的插件覆蓋了不同研發(fā)階段（如本地編碼階段，自動(dòng)化全量測(cè)試階段、CodeReview增量檢測(cè)階段）的代碼規(guī)約檢測(cè)。通過(guò)本地結(jié)合線上、全量結(jié)合增量的策略，我們實(shí)現(xiàn)了一套規(guī)則落地多端，進(jìn)而將阿里巴巴Java編碼規(guī)約通過(guò)工具化平臺(tái)化的手段在阿里內(nèi)部進(jìn)行了充分落地。2017年10月份，我們?cè)贕itHub上將P3C規(guī)則和工具的源碼正式對(duì)外開(kāi)源。

通過(guò)以上努力，我們不僅將P3C工具在阿里巴巴集團(tuán)內(nèi)部進(jìn)行了有效落地，同時(shí)在集團(tuán)外也樹(shù)立了很強(qiáng)的品牌影響力。規(guī)約檢測(cè)工具保證了規(guī)約文化的落地及傳播，同時(shí)規(guī)約文化又從效能、人才、穩(wěn)定性等方面正向推動(dòng)了整個(gè)研發(fā)體系的完善。

代碼質(zhì)量—缺陷檢測(cè)技術(shù)PRECFIX技術(shù)揭秘

由于阿里巴巴集團(tuán)業(yè)務(wù)發(fā)展的復(fù)雜性，上文提到的P3C、PMD等傳統(tǒng)自動(dòng)化檢測(cè)工具不能完全解決阿里巴巴面臨的代碼質(zhì)量問(wèn)題。因?yàn)閭鹘y(tǒng)工具多是基于規(guī)則匹配，不需要了解特定的場(chǎng)景，基于業(yè)務(wù)場(chǎng)景的BUG很難通過(guò)這些自動(dòng)化工具識(shí)別出來(lái)。例如有眾多的缺陷類型難以定義，這樣就沒(méi)辦法提取出有效的匹配規(guī)則。因此我們希望有一種對(duì)缺陷類型泛化能力比較強(qiáng)的缺陷檢測(cè)方法或者工具，于是提出了PRECFIX方法（Patch Recommendation by Empirically Clustering）。

PRECFIX的技術(shù)思路其實(shí)并不復(fù)雜，主要分為三步，首先從代碼提交數(shù)據(jù)中提取“缺陷修復(fù)對(duì)”，然后將相似的“缺陷修復(fù)對(duì)”聚類，最后對(duì)聚類結(jié)果進(jìn)行模板提取，這個(gè)缺陷檢測(cè)和補(bǔ)丁推薦技術(shù)可以用于代碼評(píng)審，全庫(kù)離線掃描等等。用戶的反饋以及我們?nèi)斯さ膶彶榭梢赃M(jìn)一步提高模型推薦質(zhì)量。

與國(guó)外友商的產(chǎn)品對(duì)比，PRECFIXP具有毫秒級(jí)檢測(cè)，覆蓋較多的場(chǎng)景，能修復(fù)部分偏業(yè)務(wù)缺陷等特性。

PRECFIX方法已經(jīng)在阿里巴巴集團(tuán)內(nèi)部落地，在內(nèi)部公開(kāi)庫(kù)中掃描出了800多種缺陷類型，3萬(wàn)多個(gè)缺陷，提取出了3000多個(gè)模板。此功能將在這個(gè)月底前（2020年4月）通過(guò)云效代碼管理平臺(tái)（Codeup）開(kāi)放給用戶使用。

代碼安全-敏感信息檢測(cè)SecretRadar

我們知道每天都有成千上萬(wàn)條諸如API Key、 Database credential、Private token等敏感信息通過(guò)某些站點(diǎn)被無(wú)意識(shí)的泄露出去。為了預(yù)防這類問(wèn)題，我們決定在云效代碼管理平臺(tái)（Codeup）提供敏感信息檢測(cè)的能力。

因此調(diào)研了業(yè)內(nèi)多款敏感信息檢測(cè)產(chǎn)品，包括比較知名的Truffle Hog、Watchtower等。但是這些工具要么單純考慮規(guī)則匹配，要么采用信息熵技術(shù)，召回率或準(zhǔn)確率無(wú)法滿足我們的預(yù)期，模型最終效果都不是非常理想。因此，我們?cè)谝?guī)則匹配和信息熵技術(shù)的基礎(chǔ)上，結(jié)合了多層檢測(cè)模型和上下文語(yǔ)義檢測(cè)，打造了一款敏感信息檢測(cè)工具 ——SecretRadar，從而使識(shí)別效果得到了顯著提升。

SecretRadar的實(shí)現(xiàn)思路主要分為三個(gè)層面，第一層我們采用傳統(tǒng)敏感信息識(shí)別技術(shù)通過(guò)豐富的規(guī)則集來(lái)保證模型基礎(chǔ)能力的穩(wěn)定和可靠，同時(shí)確保了模型良好的可擴(kuò)展性，以此來(lái)支持后續(xù)用戶自定義的能力。但是這種方法非常依賴固化的長(zhǎng)度、前綴、變量名等，匹配效果上容易造成漏報(bào)。因此針對(duì)難以固定規(guī)則捕捉的場(chǎng)景，在第二層我們采用了信息熵算法。信息熵可以用來(lái)衡量數(shù)據(jù)集的信息量大小，也就是其不確定程度。所以數(shù)據(jù)集的信息熵越大，無(wú)序程度就越高。通過(guò)計(jì)算信息熵，可以有效識(shí)別隨機(jī)生成的密文信息，從而提升模型的召回能力，補(bǔ)足基于規(guī)則手段的漏報(bào)問(wèn)題。同樣信息熵算法也有其局限性，伴隨召回的提升是誤報(bào)率的增加。因此在第三層我們采用了模板聚類的方法，進(jìn)行了過(guò)濾優(yōu)化。針對(duì)信息熵結(jié)果集聚合提取常見(jiàn)關(guān)鍵字，并結(jié)合上下文分析，來(lái)完成二次過(guò)濾。同時(shí)通過(guò)問(wèn)題的修復(fù)情況，建立二分類數(shù)據(jù)集，完成算法優(yōu)化。進(jìn)而從詞法識(shí)別迭代為語(yǔ)義識(shí)別。

智能評(píng)審助力開(kāi)發(fā)者提升研發(fā)效能

在研發(fā)提效方面，我們認(rèn)為代碼評(píng)審是一個(gè)很好的抓手。在調(diào)研、學(xué)習(xí)了國(guó)際上多款優(yōu)秀產(chǎn)品的基礎(chǔ)上，結(jié)合阿里巴巴復(fù)雜、多樣的研發(fā)場(chǎng)景，我們歷時(shí)兩年打磨出來(lái)一套非常好用的代碼評(píng)審模塊。結(jié)合人工智能技術(shù)，我們?cè)跇I(yè)內(nèi)首創(chuàng)了評(píng)審耗時(shí)預(yù)估、評(píng)審人自動(dòng)推薦等功能。

接下來(lái)我們?cè)敿?xì)了解一下評(píng)審耗時(shí)預(yù)估。“評(píng)審耗時(shí)預(yù)估”有什么意義呢？我們都知道，代碼評(píng)審的工作量“可大可小”，主要取決于評(píng)審代碼改動(dòng)量的大小和業(yè)務(wù)邏輯的復(fù)雜度。作為軟件開(kāi)發(fā)工程師，大家平時(shí)的工作都很忙，只能在開(kāi)會(huì)或編碼的間隙中抽出特定時(shí)間來(lái)做代碼評(píng)審。但往往代碼評(píng)審的工作量超出了評(píng)審者的預(yù)期。同時(shí)也存在一些極端情況，某些小的評(píng)審可能只需要幾十秒就可以評(píng)審?fù)戤?，但是評(píng)審者在不知情的情況下卻為它安排了大段的評(píng)審時(shí)間。

“評(píng)審耗時(shí)預(yù)估”主要服務(wù)于兩種場(chǎng)景，第一個(gè)場(chǎng)景是用戶在未進(jìn)行評(píng)審之前，可以在第一時(shí)間知曉評(píng)審的工作量，輔助他合理安排評(píng)審時(shí)間；第二個(gè)場(chǎng)景是對(duì)于那些同時(shí)要進(jìn)行多個(gè)代碼評(píng)審的用戶，可以幫助他們合理安排評(píng)審的優(yōu)先級(jí)。

“評(píng)審耗時(shí)預(yù)估”到底是如何實(shí)現(xiàn)的呢？首先我們基于阿里巴巴集團(tuán)內(nèi)部海量的公開(kāi)代碼數(shù)據(jù)，收集了幾百萬(wàn)次的評(píng)審文件瀏覽數(shù)據(jù)，提取了包括文本改動(dòng)、項(xiàng)目歷史、行為歷史在內(nèi)的數(shù)十種特種，訓(xùn)練了機(jī)器學(xué)習(xí)模型。當(dāng)開(kāi)發(fā)者提交代碼評(píng)審之時(shí)，我們根據(jù)他提交代碼的Diff內(nèi)容，自動(dòng)估算出評(píng)審耗時(shí)，并伴隨代碼評(píng)審?fù)ㄖ黄饋?lái)告知評(píng)審者，幫助他合理安排評(píng)審時(shí)間。以上能力會(huì)在用戶授權(quán)的情況下，陸續(xù)在云效代碼管理平臺(tái)上開(kāi)放給大家使用。

我們希望在不久的將來(lái)，開(kāi)發(fā)者不僅將代碼托管到云上，整個(gè)開(kāi)發(fā)過(guò)程也可以搬到云上。云效代碼管理平臺(tái)（Codeup）目前正在以每周一個(gè)小版本每月一個(gè)大版本的速度迭代演進(jìn)，在保證高可用、高性能、高體驗(yàn)的同時(shí)，旨在給企業(yè)開(kāi)發(fā)者和管理帶來(lái)更有價(jià)值的創(chuàng)新。目前所有開(kāi)發(fā)者都可以通過(guò)云效官網(wǎng)免費(fèi)使用Codeup，也歡迎大家加入云效開(kāi)發(fā)者交流群（釘釘群號(hào)：34532418）來(lái)與我們交流討論。