文/徐瑱 鄧?yán)?br>

在傳統(tǒng)IT項(xiàng)目開發(fā)過(guò)程中，團(tuán)隊(duì)最害怕的便是在交付前的集成測(cè)試階段突然發(fā)現(xiàn)bug而導(dǎo)致項(xiàng)目延遲甚至項(xiàng)目失敗。而如今，憑借先進(jìn)的持續(xù)集成技術(shù)，我們可以在開發(fā)過(guò)程中及時(shí)判斷開發(fā)趨勢(shì)，發(fā)現(xiàn)開發(fā)漏洞并做出有效的判斷。每天進(jìn)行多次集成，每次集成通過(guò)自動(dòng)化的構(gòu)建進(jìn)行驗(yàn)證，從而盡早發(fā)現(xiàn)集成錯(cuò)誤，極大程度地保證了項(xiàng)目開發(fā)的進(jìn)程與質(zhì)量。在下文中，我們將詳細(xì)討論如何通過(guò)SonarQube代碼質(zhì)量管理系統(tǒng)以及Jenkins工具實(shí)現(xiàn)自動(dòng)化持續(xù)集成。

開發(fā)團(tuán)隊(duì)的協(xié)作中不可避免的存在以下問(wèn)題：

1.?新手。項(xiàng)目組的實(shí)習(xí)生由于初來(lái)乍到對(duì)于軟件開發(fā)經(jīng)驗(yàn)不足，而項(xiàng)目在人手又不夠的情況下直接將新人拉入正式環(huán)境工作，為項(xiàng)目埋下不規(guī)范代碼的隱患。

2.?人員流動(dòng)。老員工維護(hù)的模塊可能不易于新員工的維護(hù)，由于工作交接不到位、水平層次和編碼習(xí)慣不同的原因造成低質(zhì)量代碼的出現(xiàn)。

3.?代碼規(guī)范意識(shí)薄弱或者疏忽。有些開發(fā)人員可能沒(méi)有接受過(guò)專門的質(zhì)量培訓(xùn)，或者在編碼時(shí)疏忽了一些規(guī)則，隨意編寫不規(guī)范的代碼。

以上問(wèn)題會(huì)導(dǎo)致項(xiàng)目的維護(hù)效率低下，代碼交接變得困難，有潛在的性性能和安全問(wèn)題等等。因此，代碼質(zhì)量審查是現(xiàn)代開發(fā)團(tuán)隊(duì)必不可少的過(guò)程。

如何解決：

代碼復(fù)查(Code Review)是很不錯(cuò)的一個(gè)解決方案，即讓項(xiàng)目Leader或者有經(jīng)驗(yàn)的員工專門對(duì)成員的代碼進(jìn)行復(fù)查。但是代碼復(fù)查的人力代價(jià)太大，試想將項(xiàng)目有經(jīng)驗(yàn)的員工拉取做代碼復(fù)查，開發(fā)進(jìn)度勢(shì)必會(huì)受到影響，而且軟件項(xiàng)目通常是龐大的，其工作量可想而知。因此，在人工之外，我們討論一種利用機(jī)器的自動(dòng)化代碼審查工具SonarQube。

SonarQube利刃：

SonarQube為代碼的質(zhì)量管理提供了一個(gè)平臺(tái)，對(duì)傳統(tǒng)的靜態(tài)檢測(cè)如PMD和findBugs等工具進(jìn)行整合，并且提供了豐富而強(qiáng)大的插件，以適用于各種語(yǔ)言的代碼質(zhì)量分析。

支持的語(yǔ)言：Java, C/C++, Objective-C, C#, PHP, Flex, Groovy, JavaScript, Python, PL/SQL, COBOL等。

支持安卓代碼審查

審查重復(fù)代碼，代碼標(biāo)準(zhǔn)，單元測(cè)試，測(cè)試覆蓋率，代碼復(fù)雜度，潛在的bug，多余的注釋，代碼設(shè)計(jì)和結(jié)構(gòu)等，提供多方面的報(bào)告。

記錄評(píng)審歷史，提供多種視圖的評(píng)估報(bào)告圖表。

提供完全的自動(dòng)化分析：可以和Maven,Ant,Gradle整合，也可以整合持續(xù)集成工具，如Jenkins。

可以使用插件擴(kuò)展

通過(guò)實(shí)現(xiàn)SQALE(基于軟件生命周期的質(zhì)量評(píng)定)來(lái)評(píng)估技術(shù)債務(wù)。