[發(fā)明專利]一種基于集中式管理模式下的前端代碼自動(dòng)化校驗(yàn)方法

在審

• 申請(qǐng)?zhí)枺?/td>: 202111152243.3
• 申請(qǐng)日: 2021-09-29
• 公開（公告）號(hào): CN113918162A
• 公開（公告）日: 2022-01-11
• 發(fā)明（設(shè)計(jì)）人: 羅金蓉;范淵;吳永越;鄭學(xué)新;劉韜
• 申請(qǐng)（專利權(quán)）人: 成都安恒信息技術(shù)有限公司
• 主分類號(hào): G06F8/41
• 分類號(hào): G06F8/41;G06F8/71;G06F11/36
• 代理公司: 成都君合集專利代理事務(wù)所(普通合伙) 51228
• 代理人: 尹新路

本發(fā)明涉及計(jì)算機(jī)自動(dòng)化校驗(yàn)技術(shù)領(lǐng)域，公開了一種基于集中式管理模式下的前端代碼自動(dòng)化校驗(yàn)方法，包括：預(yù)設(shè)待激活的自動(dòng)化代碼檢查規(guī)則；并將所述待激活的自動(dòng)化代碼檢查規(guī)則配置進(jìn)所述前端代碼項(xiàng)目中；用戶根據(jù)托管方式選擇對(duì)應(yīng)的自動(dòng)化代碼檢查規(guī)則；選擇自動(dòng)化代碼檢查規(guī)則的類型；激活對(duì)應(yīng)托管方式和類型的自動(dòng)化代碼檢查規(guī)則；在所述待校驗(yàn)的前端代碼項(xiàng)目中編輯前端代碼，并根據(jù)激活的自動(dòng)化代碼檢查規(guī)則對(duì)前端代碼進(jìn)行第一次自動(dòng)化代碼校驗(yàn)和第一次代碼修復(fù)；根據(jù)自動(dòng)化代碼檢查規(guī)則對(duì)待校驗(yàn)的前端代碼項(xiàng)目繼續(xù)檢查，對(duì)前端代碼進(jìn)行對(duì)應(yīng)的第二次代碼自動(dòng)化校驗(yàn)和第二次自動(dòng)代碼修復(fù)，判斷輸出的校驗(yàn)結(jié)果是否正確，并將前端代碼入庫(kù)。

技術(shù)領(lǐng)域

本發(fā)明涉及計(jì)算機(jī)自動(dòng)化校驗(yàn)技術(shù)領(lǐng)域，具體地說，是一種基于集中式管理模式下的前端代碼自動(dòng)化校驗(yàn)方法，用于支持代碼集中管理場(chǎng)景下的代碼自動(dòng)化檢查和自動(dòng)化修復(fù)，提升檢查效率和修復(fù)正確率。

背景技術(shù)

CR（Code Review，代碼審查/代碼走查）是每家公司每個(gè)產(chǎn)品團(tuán)隊(duì)都會(huì)必做的一件事情，特別是作為安全公司，對(duì)代碼審查更是格外看重。CR有效的規(guī)范了前端代碼編寫風(fēng)格，可有效降低代碼的閱讀成本和代碼錯(cuò)誤，同時(shí)也大幅度提升了代碼的可讀性、健壯性，降低后期維護(hù)成本。目前常用的CR主要有如下幾種方式：在前后端不分離的項(xiàng)目模式下，大多是采用人工CR的模式，即通過采用某些插件/系統(tǒng)實(shí)現(xiàn)自動(dòng)從代碼版本庫(kù)中獲取代碼的提交記錄，然后自動(dòng)創(chuàng)建想要的CR任務(wù)，并按照自定義的規(guī)則，自動(dòng)將CD任務(wù)分配給對(duì)應(yīng)的代碼評(píng)審員，也支持手動(dòng)方式進(jìn)行分配，例如常見的Redmine（基于web的項(xiàng)目管理軟件）項(xiàng)目管理工具。這種人工CR方式有它存在的優(yōu)點(diǎn)，但存在的問題也是非常明顯，如下：審查效率非常低；代碼錯(cuò)誤識(shí)別率非常低；走查覆蓋率低，結(jié)論可信度低，遇到項(xiàng)目時(shí)間很緊張的情況下，大多也是走馬觀花，結(jié)論變得不可信，沒有達(dá)到CR的真正目的；這種方式要求代碼要先上庫(kù)，錯(cuò)誤代碼依然上庫(kù)成功，未做到代碼上庫(kù)前的提前檢查；在前后端分離的項(xiàng)目模式下，仍有部分采用的是人工CR模式，但也出現(xiàn)了不少的工具可以幫我們自動(dòng)去做這些CR，解決掉大部分人工CR面臨的一些問題，比如：效率低、錯(cuò)誤識(shí)別覆蓋不準(zhǔn)確等等。現(xiàn)在針對(duì)項(xiàng)目源代碼管理主要是兩種方式：SVN和GIT，這兩種源代碼管理工具均提供一些校驗(yàn)鉤子，來保證代碼commit倉(cāng)庫(kù)前觸發(fā)對(duì)應(yīng)的檢驗(yàn)規(guī)則來自動(dòng)化檢查代碼格式，以及編碼錯(cuò)誤，提升代碼質(zhì)量，防止不規(guī)范代碼被提交到代碼倉(cāng)庫(kù)。SVN方式屬于集中式的版本控制系統(tǒng)，而GIT方式屬于分布式的版本控制系統(tǒng)，兩者各有優(yōu)缺點(diǎn)，所以目前市面上兩者的使用都還很活躍，特別是一些歷史已上線項(xiàng)目，大多的項(xiàng)目相關(guān)文檔及代碼都是使用SVN進(jìn)行托管，畢竟SVN易于管理，集中式服務(wù)器的運(yùn)作模式更能保證安全性，特別是在一些傳統(tǒng)安全公司SVN的應(yīng)用十分廣泛。在這樣的背景下，我們需要借助SVN提供的鉤子來進(jìn)行代碼自動(dòng)化檢查則會(huì)出現(xiàn)如下問題：

（1）在代碼集中式管理場(chǎng)景下，通常代碼倉(cāng)庫(kù)（服務(wù)端）的配置權(quán)限非常高，一般僅是管理員才具備相關(guān)服務(wù)器的配置權(quán)限，盡管我們可以在服務(wù)器端的hooks文件夾內(nèi)配置一些較為常用的鉤子，比如pre-commit.bat、post-commit.bat等，來用作代碼提交前的自動(dòng)檢查，但是因?yàn)闊o法拿到管理員權(quán)限此方法變得不可用。

（2）畢竟集中管理的服務(wù)器上存著公司大部分的項(xiàng)目，所以上述（1）大多數(shù)是行不通的。轉(zhuǎn)移到客戶端設(shè)置，需要在Hook Script中填寫Hook類型及相關(guān)的腳本路徑及命令行。配置檢查腳本繁瑣且無法保證項(xiàng)目組中的每個(gè)成員都進(jìn)行了hooks配置，當(dāng)然也可以通過編寫批量處理腳本修改注冊(cè)表信息來實(shí)現(xiàn)，但仍然存在無法統(tǒng)一用戶配置的問題。

（3）大多數(shù)程序員喜歡直接命令行方式進(jìn)行操作，不使用上述（2）中的客戶端進(jìn)行代碼提交時(shí)無法觸發(fā)對(duì)應(yīng)的客戶端鉤子校驗(yàn)。

（4）在上述（1）或者（2）都能成功配置的前提下，歷史項(xiàng)目文件數(shù)目龐大，一次性應(yīng)用規(guī)則到整個(gè)項(xiàng)目，可能導(dǎo)致大量文件觸發(fā)語法錯(cuò)誤，從而使得項(xiàng)目運(yùn)作變得不可控，再加上維護(hù)者對(duì)歷史代碼熟悉度不高，修復(fù)難度及成本變得十分高。