目前PRECFIX技術(shù)已經(jīng)在阿里巴巴集團(tuán)內(nèi)部落地并獲得好評(píng)，關(guān)于“PRECFIX”技術(shù)的論文被國(guó)際軟件工程大會(huì)(ICSE)收錄。

張昕東(別象) 阿里巴巴 云研發(fā)事業(yè)部 算法工程師

阿里巴巴在缺陷檢測(cè)技術(shù)方面遇到的三個(gè)挑戰(zhàn)

編碼是DevOps的重要一環(huán)，我所在的部門主要負(fù)責(zé)阿里巴巴集團(tuán)的代碼托管。在平臺(tái)業(yè)務(wù)的背后，我們建設(shè)了一系列智能化能力用來賦能前線業(yè)務(wù)。依賴底層的代碼圖譜和離線數(shù)倉(cāng)(離線數(shù)據(jù)倉(cāng)庫(kù))的數(shù)據(jù)能力，代碼智能衍生出了缺陷檢測(cè)、代碼生成、代碼克隆、代碼安全等能力。今天主要介紹一下我們?cè)谌毕輽z測(cè)領(lǐng)域的初步探索和實(shí)踐。

缺陷檢測(cè)和補(bǔ)丁推薦幾十年來一直是軟件工程領(lǐng)域的難題，又是研究者和一線開發(fā)者最為關(guān)心的問題之一。這里講的缺陷不是網(wǎng)絡(luò)漏洞、系統(tǒng)缺陷，而是隱藏在代碼中的缺陷，也就是程序員們戲稱的“八阿哥”(即BUG)。每位開發(fā)者都希望有一種智能的缺陷檢測(cè)技術(shù)來提升代碼質(zhì)量，避免踩坑。所謂“最迷人的最危險(xiǎn)”，如此令人著迷的技術(shù)自然有著重重阻礙。

在研究了現(xiàn)有的一些解決方法以及阿里巴巴內(nèi)部數(shù)據(jù)集的特征后，我們將缺陷檢測(cè)技術(shù)在阿里巴巴產(chǎn)品落地上的挑戰(zhàn)歸納為三個(gè)方面：

復(fù)雜的業(yè)務(wù)環(huán)境

首先阿里巴巴經(jīng)濟(jì)體業(yè)務(wù)種類繁多，有底層系統(tǒng)中間件的代碼，有物流的代碼，也有安全、人工智能等各個(gè)領(lǐng)域的代碼，業(yè)務(wù)在變，代碼缺陷類型也在變。代碼數(shù)據(jù)只增不減，代碼缺陷類型捉摸不透，缺陷檢測(cè)的困難不言自明。

以Java語言為例，學(xué)術(shù)界的Java缺陷公開數(shù)據(jù)集常用的是Defect4J。Defect4J包含6個(gè)代碼庫(kù)，有將近400個(gè)人工確認(rèn)的缺陷和補(bǔ)丁。這些代碼庫(kù)是比較基礎(chǔ)常規(guī)的代碼庫(kù)，缺陷種類容易劃分，一部分研究者也做了特定缺陷種類的研究，對(duì)癥下藥效果尚可，然而換了一種缺陷類型，那么檢測(cè)的效果就很難令人滿意了。

在阿里巴巴數(shù)據(jù)集中，有眾多的缺陷類型難以定義，希望能有一種對(duì)缺陷類型泛化能力強(qiáng)的缺陷檢測(cè)與補(bǔ)丁推薦的方法，不說“包治百病藥到病除”，但希望能夠適應(yīng)不同的“病癥”，提高代碼“免疫力”。

有限的輔助資源

第二大挑戰(zhàn)來源于有限的輔助資源，這也是導(dǎo)致許多學(xué)術(shù)界相關(guān)成果無法直接復(fù)現(xiàn)利用的原因。

何謂輔助資源，常用者有三：測(cè)試用例，缺陷報(bào)告，缺陷標(biāo)簽。

雖然大多數(shù)線上代碼都已經(jīng)達(dá)到了很高的測(cè)試覆蓋率，但是由于代碼質(zhì)量參差，有一大部分代碼庫(kù)是缺乏測(cè)試用例的，我們也缺少足夠的缺陷報(bào)告去直接定位缺陷。我們也想嘗試過通過缺陷標(biāo)簽來學(xué)習(xí)缺陷模式，然而自動(dòng)打標(biāo)簽的方法準(zhǔn)確率不高，而人工給如此龐大的數(shù)據(jù)集打標(biāo)簽是不太現(xiàn)實(shí)的。

產(chǎn)品落地的要求

而最難現(xiàn)實(shí)的是第三大挑戰(zhàn)，來自產(chǎn)品的落地要求。

作為一項(xiàng)技術(shù)，需要在產(chǎn)品中尋找落地的機(jī)會(huì)。而真實(shí)的落地又對(duì)技術(shù)有極高的要求：我們構(gòu)想的主要落地場(chǎng)景是代碼評(píng)審中的缺陷靜態(tài)掃描及補(bǔ)丁推薦。產(chǎn)品經(jīng)理說：“檢測(cè)過程要高效，盡量不要給誤報(bào)，定位缺陷還不夠，補(bǔ)丁方案還得讓用戶知道。”

業(yè)界和學(xué)術(shù)界較為流行的缺陷檢測(cè)手段和其局限性

搞研究做創(chuàng)新自然不能固步自封，閉門造車。我先來給大家簡(jiǎn)單地介紹一些相關(guān)領(lǐng)域的一些現(xiàn)有成果。

主要從缺陷檢測(cè)，補(bǔ)丁推薦，以及其他相關(guān)的技術(shù)應(yīng)用三個(gè)方面做介紹。

缺陷定位技術(shù)

關(guān)于缺陷定位技術(shù)的這些歸納總結(jié)主要來自于熊英飛老師(北京大學(xué)新體制副教授)的論文。主要方法大類有：基于光譜的缺陷定位，基于突變的缺陷定位，堆棧分析等等。

比如基于光譜的缺陷定位是基于測(cè)試用例，通過的測(cè)試用例經(jīng)過的代碼行給予正向分?jǐn)?shù)，失敗的測(cè)試用例經(jīng)過的代碼路徑給予負(fù)面分?jǐn)?shù)，類似于光譜的形式將分?jǐn)?shù)較低的一些代碼行歸類為潛在缺陷行。

這些缺陷定位手段大多關(guān)注特定缺陷，在定位某些特定缺陷時(shí)準(zhǔn)確率明顯高于其它缺陷，比如Predicate Switching主要用于檢測(cè)條件語句中的bug。

第二個(gè)局限在于誤報(bào)率較高，以Defect4J數(shù)據(jù)集測(cè)試結(jié)果為例，以上方法中準(zhǔn)確率最高的是基于光譜的定位，但是TOP1的命中率也只有37%左右。有研究工作將這些各有所長(zhǎng)的缺陷定位手段整合起來一起判斷，但誤報(bào)率仍然高于50%。

最重要的一點(diǎn)是，上述的缺陷定位手段不提供補(bǔ)丁信息，這一點(diǎn)在實(shí)際應(yīng)用過程中是很致命的，比如基于光譜的定位會(huì)返回多個(gè)潛在缺陷行，但是沒有明確的修復(fù)方案，用戶會(huì)比較迷茫。

補(bǔ)丁推薦技術(shù)

關(guān)于補(bǔ)丁推薦技術(shù)，比較具有代表性的研究是Generate-and-validate approach，這種類型下的研究成果大體思路是基于失敗的測(cè)試用例，定位到代碼上下文，然后通過隨機(jī)替換代碼元素，或基于語義不斷嘗試改變抽象語法樹上的結(jié)點(diǎn)，并利用測(cè)試用例或其它可驗(yàn)證信息去驗(yàn)證修改的結(jié)果，直到測(cè)試用例或其他驗(yàn)證手段跑通。

這些補(bǔ)丁生成的方法主要有三大局限，首先是準(zhǔn)確率低，主要體現(xiàn)在Overfitting(過度擬合)問題上，意思是生成的修復(fù)片段和現(xiàn)實(shí)中工程師實(shí)際的修復(fù)方式不同，有些修復(fù)甚至是面向測(cè)試用例的修復(fù)而不是面向真實(shí)缺陷的修復(fù)。左圖是某論文中一個(gè)Overfitting的例子，“Generate-and-validate”方法將if條件修改為了一個(gè)無意義的恒等于true的條件，使得該方法每次安全地return，這樣的修改確實(shí)能跑通測(cè)試用例，但是對(duì)真實(shí)的bug是無濟(jì)于事的。

第二個(gè)明顯的局限是耗時(shí)長(zhǎng)，消耗的計(jì)算資源較多，這種修復(fù)方法往往是小時(shí)級(jí)的，而且他是基于編譯的，需要不斷地測(cè)試運(yùn)行，效率較低。

此外，這種方法對(duì)測(cè)試用例完備性的要求非常高，它既考驗(yàn)測(cè)試的覆蓋率，又考驗(yàn)了測(cè)試用例設(shè)計(jì)的合理性。

其它應(yīng)用技術(shù)

還有一些缺陷檢測(cè)或補(bǔ)丁推薦技術(shù)，可能大家有所耳聞，特別是Facebook和Google的，我也簡(jiǎn)單地介紹下。

• Simfix和CBCD主要是基于缺陷報(bào)告的補(bǔ)丁生成，利用代碼克隆把缺陷報(bào)告和補(bǔ)丁遷移到新代碼上。
• Ubisoft的CLEVER首先基于特征做了commit級(jí)別的缺陷預(yù)測(cè)，對(duì)風(fēng)險(xiǎn)較大的一些commit做二次檢測(cè)，二次檢測(cè)的方法是將缺陷報(bào)告根據(jù)代碼的dependency聚類起來，然后做抽象語法樹的節(jié)點(diǎn)相似度比較，游戲代碼往往有一些相似的缺陷。
• Bugram是將代碼解析成token序列，利用Ngram算法來預(yù)測(cè)出現(xiàn)某一個(gè)token的概率，概率低的token可能是個(gè)缺陷點(diǎn)，這種方法當(dāng)代碼復(fù)雜度變高或代碼詞匯數(shù)量過大后，效果就急劇下降。
• Infer，Getafix，Sapfix都是Facebook提出的，做的都很不錯(cuò)。Sapfix主要是針對(duì)移動(dòng)手機(jī)的UI做類似Fuzzing的缺陷檢測(cè)，Infer主要針對(duì)代碼的NPE問題做了偏規(guī)則的檢查，所以準(zhǔn)確率較高，Getafix是在Infer的檢測(cè)結(jié)果的基礎(chǔ)之上，對(duì)工程師修復(fù)的補(bǔ)丁做了模式聚類，將常用的NPE修復(fù)模式統(tǒng)計(jì)生成出來。
• Tricorder和Findbugs等工具都是比較成熟的代碼檢測(cè)器，開發(fā)者可以基于這之上定制自己的檢測(cè)機(jī)制，但比較依賴規(guī)則的人工制定。

我們?yōu)槭裁刺岢鯬RECFIX方法

經(jīng)過調(diào)研后，我們發(fā)現(xiàn)外部的已有技術(shù)方法不能完全解決阿里巴巴面臨的挑戰(zhàn)和問題，于是我們提出了PRECFIX方法。

我們首先在阿里巴巴數(shù)據(jù)集中復(fù)現(xiàn)了一個(gè)基于特征工程的commit級(jí)別缺陷風(fēng)險(xiǎn)檢測(cè)，這個(gè)在之前講Ubisoft的Clever的時(shí)候有提過，具體方法是從代碼數(shù)據(jù)集中根據(jù)托管系統(tǒng)Git建立commit父子關(guān)系圖，利用改進(jìn)的SZZ方法對(duì)commit進(jìn)行自動(dòng)打標(biāo)簽，然后抽取出一部分特征如下所示，然后利用Xgboost 或者隨機(jī)森林對(duì)特征和標(biāo)簽進(jìn)行訓(xùn)練，將模型用于commit風(fēng)險(xiǎn)的檢測(cè)。特征主要分為規(guī)模、代碼分布、目的、開發(fā)者經(jīng)驗(yàn)以及文件修改五大維度，共14個(gè)子特征。

以SZZ算法作為標(biāo)簽數(shù)據(jù)的模型在準(zhǔn)確率上有瓶頸。SZZ算法雖然邏輯合理，在公開數(shù)據(jù)集上有比較好的表現(xiàn)，然而在我們的代碼數(shù)據(jù)集上，準(zhǔn)確率不高，人工觀察了數(shù)百條SZZ算法標(biāo)注的缺陷commit，其中僅有53%是真實(shí)的修復(fù)行為。“噪聲點(diǎn)”主要來自以下幾種場(chǎng)景：業(yè)務(wù)型的修復(fù)與代碼無關(guān)，注解日志的改動(dòng)，測(cè)試類的調(diào)整，代碼風(fēng)格的優(yōu)化，代碼改動(dòng)本身是用于“debug”的所以message中帶有“debug”信息等等。

而更進(jìn)一步，僅有37%的修復(fù)型代碼改動(dòng)可以遷移到新的代碼上，這也就意味著有些代碼改動(dòng)雖然是真實(shí)的修復(fù)，但是由于改動(dòng)量過于復(fù)雜，或者只與特定環(huán)境，特定上下文相關(guān)，沒有可借鑒的價(jià)值。

通過對(duì)標(biāo)簽數(shù)據(jù)的細(xì)致分析，我們認(rèn)為自動(dòng)化的標(biāo)簽不滿足我們的需求，而且打缺陷標(biāo)簽對(duì)打標(biāo)者的技術(shù)要求較高，對(duì)海量的代碼改動(dòng)歷史打標(biāo)簽也是不現(xiàn)實(shí)的。

我們開始不盲目尋找和復(fù)現(xiàn)方法，而是用心去感受和發(fā)現(xiàn)開發(fā)者在日常開發(fā)過程中的修復(fù)行為，我們總結(jié)了以下幾點(diǎn)：首先，借鑒于SZZ算法，commit message中往往包含了用戶的修復(fù)意圖，可以依據(jù)commit message來過濾出一部分?jǐn)?shù)據(jù)。另外我們?cè)谡{(diào)研SZZ算法數(shù)據(jù)時(shí)，發(fā)現(xiàn)75%的修復(fù)提交都有這樣的模式：刪除一些缺陷代碼,然后新增一些代碼，比如修改了一個(gè)參數(shù)，在diff中便是刪除了一行，新增了一行。

還觀察到一個(gè)細(xì)節(jié)就是一個(gè)修復(fù)的操作往往涉及的文件數(shù)不超過兩個(gè)，而一些不太規(guī)范的commit里面含有大量的文件，即使里面包含了修復(fù)行為，也會(huì)被稀釋掉，引入不被歡迎的噪音。

同時(shí)我們也調(diào)研了在代碼評(píng)審階段用戶比較關(guān)心的缺陷，如故障點(diǎn)、重構(gòu)點(diǎn)、代碼風(fēng)格、性能問題等等，很多問題都有重復(fù)出現(xiàn)、重復(fù)修改的記錄。我們萌生了從海量的提交歷史中挖掘出重復(fù)常見的缺陷，防止開發(fā)者再次犯錯(cuò)的想法。

于是我們提出了：

這次ICSE收錄的論文中描述的方法,后期會(huì)在云效產(chǎn)品中使用，其實(shí)思路方法比較直接簡(jiǎn)潔，主要分為三步，首先從代碼提交數(shù)據(jù)中提取“缺陷修復(fù)對(duì)”，然后將相似的“缺陷修復(fù)對(duì)”聚類，最后對(duì)聚類結(jié)果進(jìn)行模板提取，這個(gè)缺陷檢測(cè)和補(bǔ)丁推薦技術(shù)可以用于代碼評(píng)審，全庫(kù)離線掃描等等。用戶的反饋以及我們?nèi)斯さ膶彶榭梢赃M(jìn)一步提高模型推薦質(zhì)量。

實(shí)現(xiàn)PRECFIX方法的技術(shù)細(xì)節(jié)

接下來我們聊一下實(shí)現(xiàn)PRECFIX方法的技術(shù)細(xì)節(jié)。首先是“缺陷修復(fù)對(duì)提取”。有朋友可能會(huì)有疑問，何為“缺陷修復(fù)對(duì)”？“缺陷修復(fù)對(duì)”如何提取？

缺陷修復(fù)對(duì)提取

這得先從幾個(gè)數(shù)字講起。SZZ算法利用Blame信息去追溯引入缺陷的commit以及缺陷行，我們觀察發(fā)現(xiàn)，有25%的文件的缺陷行源自多個(gè)文件，這就意味著利用blame信息去溯源可能會(huì)將一個(gè)缺陷追溯到兩個(gè)源頭，而將一個(gè)缺陷的代碼行一分為二很有可能是沒有意義的。

通過blame信息去追溯缺陷代碼行不夠準(zhǔn)確，而我們想要的缺陷相關(guān)的代碼上下文實(shí)際上就是這次修復(fù)型commit提交前該文件最后一次提交的內(nèi)容，我們可以直接通過本次提交的文件和對(duì)應(yīng)的diff還原出本次提交前的文件內(nèi)容。

我們發(fā)現(xiàn)，大多數(shù)的修復(fù)行為是以方法為單位的，所以我們提出了以方法為單位的“缺陷修復(fù)對(duì)”提取方法，即將方法體內(nèi)的diff chunks(差異文件區(qū)塊)合并，生成一個(gè)缺陷修復(fù)對(duì)。當(dāng)然也可以不以方法體為范圍，直接以diff chunk為單位去提取缺陷修復(fù)對(duì)，這些都各有利弊，如果以diff chunk為單位去提取，那就不需要源代碼信息了，直接解析diff即可。

在提取過程中有個(gè)小tips就是將缺陷片段和修復(fù)片段歸一化，比如將空格和換行符去掉，然后比較兩者，將相同的缺陷修復(fù)對(duì)過濾掉，這樣能過濾掉一部分代碼格式修改。

我們發(fā)現(xiàn)60%的commit僅包含了1-2個(gè)文件，但也存在小部分的不規(guī)范commit包含了數(shù)十個(gè)甚至上百個(gè)文件。如之前所說，我們認(rèn)為一次修復(fù)行為關(guān)聯(lián)的文件往往在三個(gè)以下，為了減小噪聲的引入，在提取缺陷修復(fù)對(duì)的過程中建立過濾機(jī)制。其實(shí)這個(gè)commit文件數(shù)量的限制是準(zhǔn)確率和召回率的權(quán)衡，在真實(shí)實(shí)踐中我們?yōu)榱苏倩芈事晕⒎艑捔讼拗?#xff0c;將閾值設(shè)為了5。

通過SZZ算法標(biāo)注的代碼缺陷47%不夠準(zhǔn)確。我們沿用了SZZ的利用commit message的數(shù)據(jù)采集步驟，所以這個(gè)缺陷修復(fù)對(duì)的提取過程還是會(huì)存在大量的噪聲難以去除。我們想到了聚類，將常見的缺陷與補(bǔ)丁聚類起來，總結(jié)成模板，一些噪聲或沒有借鑒意義的缺陷修復(fù)會(huì)被自然地過濾。

缺陷修復(fù)對(duì)聚類

提取完缺陷修復(fù)對(duì)后，為了盡量減少噪音，并且我們的目的是提取共性缺陷修復(fù)記錄，于是采用了聚類的方法，將相似的缺陷修復(fù)對(duì)聚類在一起，得到一些共性的缺陷。

由于事前無法預(yù)測(cè)類簇?cái)?shù)量，我們沒有使用Kmeans聚類算法，采用了目前比較成熟的基于密度的DBSCAN算法，當(dāng)然也可以使用pairwise的比較和合并，也就是所有情況都比一遍。

聚類方式上，我們嘗試過很多種，有單獨(dú)聚類缺陷片段的，效果不錯(cuò)，但是修復(fù)片段的分析成為了難點(diǎn)，因?yàn)橥瑯右欢稳毕萜斡胁煌男迯?fù)方案，很難自動(dòng)化地分析。我們最后嘗試了同時(shí)聚類缺陷和修復(fù)片段，這樣聚類的方式可以在匹配上缺陷片段時(shí)直接給出修復(fù)片段，不用再另外考慮如何做修復(fù)推薦。

直接使用DBSCAN效率較低，以我們的實(shí)驗(yàn)數(shù)據(jù)量來講，大概需要70個(gè)小時(shí)。于是，我們?cè)贒BSCAN的基礎(chǔ)上做了一定的優(yōu)化，主要有圖表上的幾種方式。我們基于MapReduce實(shí)現(xiàn)聚類，Mapper階段做缺陷修復(fù)對(duì)的預(yù)處理，Reducer階段跑DBSCAN。第一種優(yōu)化方式是在Mapper階段采用KDTree或者SimHash算法將比較相近的缺陷修復(fù)對(duì)分發(fā)到一個(gè)Reducer中做并行聚類，時(shí)間性能大概提升了4倍。類簇?fù)p失率主要是和基礎(chǔ)版的DBSCAN算法相比，大概損失了6%。

大多數(shù)的缺陷修復(fù)對(duì)互相之間是沒有任何關(guān)聯(lián)的，而我們利用代碼克隆技術(shù)比較兩個(gè)片段又是最耗時(shí)的部分，圖上的APISEQ便是我們優(yōu)化“不必要比較”的方法。我們洞察了這批缺陷修復(fù)對(duì)數(shù)據(jù)集，發(fā)現(xiàn)幾乎所有的片段都或多或少包含了方法調(diào)用，沒有方法調(diào)用的片段大概率是一些無意義的噪聲，所以我們可以在聚類比較的過程中先比較兩個(gè)片段是否含有相同的API，如果有的話再進(jìn)行比較，通過這個(gè)方法時(shí)間性能又提高了四倍。

我們也嘗試了比較新穎的并行DBSCAN算法，速度非常快，但是類簇?fù)p失相對(duì)較大。這個(gè)數(shù)據(jù)處理的過程是定期的離線計(jì)算，頻率較低。最終權(quán)衡之下，我們選擇了耗時(shí)相對(duì)較短，損失率較小的KDTree或APISEQ+KDTREE的聚類方法。

至于聚類過程中的兩個(gè)片段的代碼克隆比較方式，我們發(fā)現(xiàn)兩種互補(bǔ)的計(jì)算方式的結(jié)果明顯優(yōu)于單個(gè)計(jì)算方式，我們的最佳實(shí)踐是“編輯距離”和“Jaccard”的加權(quán)平均，因?yàn)椤熬庉嬀嚯x”能夠捕捉到token(代碼元素)的順序關(guān)系，而Jaccard能計(jì)算token重合比例。

模版提取與匹配

最后是“模版提取”：為了提升用戶體驗(yàn)，我們希望將同一類簇的片段聚合起來提取出模板，降低用戶的理解成本。

如上圖所示，同一類簇的兩個(gè)片段非常相似，我們先遞歸地使用最長(zhǎng)子序列算法，黃色部分為匹配的內(nèi)容。一些不匹配的內(nèi)容除了左邊的片段多了一句以外，其他部分實(shí)際上是變量名不同，我們將不同的變量名分析提取出來，存儲(chǔ)為“@Para”的格式方便后期匹配。

當(dāng)掃描到新的缺陷片段時(shí)，我們基于模板識(shí)別出它的變量名，并直接用新的變量名替換補(bǔ)丁模板中的“@Para”參數(shù)，然后自動(dòng)推薦出帶有新參數(shù)的修復(fù)建議。

下面來看幾個(gè)PRECFIX聚類得到的模板。第一大類是“合理性檢查”，修復(fù)片段做了長(zhǎng)度的判斷，合理性檢查也包括了空值檢查。

第二個(gè)類是“API變更”， API的參數(shù)發(fā)生了改變，增加了Gpu id，第一個(gè)參數(shù)的來源也做了修改。API變更還包括了方法名的改動(dòng)，參數(shù)的增刪改，這是非常常見的類型。

還有一個(gè)大類是做查看聚類結(jié)果之前沒想到的，就是“API封裝”，工程師往往會(huì)把功能獨(dú)立，經(jīng)常復(fù)用的代碼段封裝起來，減少代碼重復(fù)度和維護(hù)成本，而且工具類會(huì)將方法寫的比較完善，減少開發(fā)者在編寫時(shí)產(chǎn)生的不必要的失誤。

當(dāng)然Precfix也不是代碼缺陷的特效藥，只是提供了一種從代碼庫(kù)中挖掘缺陷的思路。模板數(shù)量和誤報(bào)率需要持續(xù)地跟進(jìn)和維護(hù)。

PRECFIX方法已經(jīng)在阿里巴巴集團(tuán)內(nèi)部落地，在內(nèi)部公開庫(kù)中掃描出了800多種缺陷類型，3萬多個(gè)缺陷，并將結(jié)果對(duì)用戶進(jìn)行了訪談，獲得了普遍的好評(píng)。后續(xù)，該方法也會(huì)在“云效”產(chǎn)品中應(yīng)用，供更多開發(fā)者使用。

---

西安創(chuàng)成軟件信息技術(shù)有限公司，新型信息化技術(shù)的提供者和信息化系統(tǒng)支撐業(yè)務(wù)系統(tǒng)的方案/開發(fā)技術(shù)提供者。

公司下設(shè)：

農(nóng)業(yè)信息化與農(nóng)業(yè)物聯(lián)網(wǎng)部：主要從事農(nóng)業(yè)信息化技術(shù)開發(fā)、應(yīng)用、推廣及服務(wù)，致力于城鄉(xiāng)融合、鄉(xiāng)村產(chǎn)業(yè)振興、農(nóng)業(yè)信息化技術(shù)研究和應(yīng)用，在智慧農(nóng)業(yè)方向上，研究新型信息化技術(shù)在農(nóng)業(yè)、農(nóng)村中的應(yīng)用和推廣。

信息系統(tǒng)集成部：主要從事新型信息化技術(shù)、智能信息化應(yīng)用、移動(dòng)互聯(lián)網(wǎng)技術(shù)(APP、小程序、云平臺(tái)等)等深度信息化的方案、智慧城市、數(shù)字城管等信息化的集成、方案咨詢等業(yè)務(wù)。

軟件技術(shù)研究中心：主要從事軟件開發(fā)技術(shù)、公司自研型軟件平臺(tái)、軟件工程應(yīng)用新技術(shù)、物聯(lián)網(wǎng)平臺(tái)、大數(shù)據(jù)與AI應(yīng)用技術(shù)、公司未來規(guī)劃新業(yè)務(wù)方向預(yù)研、新型ICT人才培養(yǎng)與輸出等業(yè)務(wù)。

歡迎大家洽談業(yè)務(wù)、交流合作！聯(lián)系方式：

聯(lián)系人：張先生

電話：13892807048

郵箱：cs_zhanght@163.com

網(wǎng)址：www.chuangcheng-software.com

關(guān)注我司，請(qǐng)掃以下二維碼：

西安創(chuàng)成軟件信息技術(shù)有限公司，一個(gè)創(chuàng)新并創(chuàng)造價(jià)值的公司，期待您的合作與加盟！

總結(jié)

以上是生活随笔為你收集整理的idea2020shezhi代码检查级别_ICT技术：阿里巴巴代码缺陷检测探索与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。