張 迪,李增揚(yáng),李 兵,梁 鵬

(武漢大學(xué) 計算機(jī)學(xué)院,武漢 430072)

1 引 言

軟件系統(tǒng)從誕生開始會發(fā)生逐漸演進(jìn).軟件演進(jìn)通常占據(jù)軟件開發(fā)生命周期的75%[1].然而,質(zhì)量的降低和復(fù)雜性增加促使了開發(fā)人員提出靈活的、可維護(hù)的、可擴(kuò)展的技術(shù)用以提高軟件的可靠性且減少修改的代價.重構(gòu)就是其中之一.根據(jù)定義,重構(gòu)是“改變軟件系統(tǒng)的過程,它不會改變代碼的外部行為,而是改進(jìn)其內(nèi)部結(jié)構(gòu)[2]”.重構(gòu)的目標(biāo)是使源代碼更簡單、更易于維護(hù)[2].軟件的可維護(hù)性可以通過代碼異味[3](code smell)來度量,而重構(gòu)是解決代碼異味的一種有效方法[1].

我們知道,開發(fā)人員經(jīng)常在版本控制系統(tǒng)的提交消息中明確聲稱他們對軟件系統(tǒng)的修改為重構(gòu)(Refactoring).所以,根據(jù)定義,重構(gòu)之后的軟件系統(tǒng)的可維護(hù)性將會得到改善.我們稱這類代碼修改為開發(fā)人員的自承認(rèn)重構(gòu)(Self-admitted refactoring,簡稱SAR).因此,一個項目的提交可以分為兩類:自承認(rèn)重構(gòu)(簡稱:SAR)和非自承認(rèn)重構(gòu)(簡稱:非SAR).一個SAR對應(yīng)的軟件代碼庫版本稱為SAR版本.目前,SAR是否改善了源代碼的結(jié)構(gòu)質(zhì)量尚未得到研究和證實(shí).

本文為了深入了解自承認(rèn)重構(gòu)現(xiàn)象,對一個大型開源軟件項目(即Fastjson)進(jìn)行了探索性案例研究.我們使用代碼異味(Code smell)來評估SAR對軟件質(zhì)量的影響.本文得到的主要結(jié)果有:1)在選定的項目中,SAR往往不增加代碼異味的數(shù)量;2)在SAR版本中,被修改的源文件數(shù)量與新引入的代碼異味之間存在顯著相關(guān)關(guān)系;3)進(jìn)行過SAR的開發(fā)者占總開發(fā)者的比例相對較小;4)SAR在軟件生命周期中分布不均衡.

本文的組織如下:第2節(jié)介紹代碼異味及其檢測工具,并介紹SAR的研究背景和相關(guān)工作;第3節(jié)描述了案例研究設(shè)計,包括研究問題、案例選取、所需收集的數(shù)據(jù)、數(shù)據(jù)收集方法、數(shù)據(jù)分析方法等;第4節(jié)給出了研究結(jié)果;第5節(jié)針對結(jié)果進(jìn)行了討論;最后,第6節(jié)給出了本文結(jié)論.

2 相關(guān)研究

在這一節(jié)中,我們將從三個方面討論與自承認(rèn)重構(gòu)領(lǐng)域相關(guān)的研究工作.

2.1 代碼異味與重構(gòu)

Fowler等人提出使用代碼異味(code smell)來表示代碼的結(jié)構(gòu)質(zhì)量問題[2].他們定義了22種常見的代碼異味,包括重復(fù)代碼(duplicated code)、狎昵關(guān)系(inappropriate intimacy)等[2].后來一些新的代碼異味被提出,例如:Kerievsky提出了5種新的代碼異味,包括條件復(fù)雜度(conditional complexity)、方案擴(kuò)展(solution sprawl)等[4].Zhang等人針對目前代碼異味的研究情況做了文獻(xiàn)綜述,他們發(fā)現(xiàn)Duplicated Code被過度研究,且很多的研究重點(diǎn)都放在了檢測代碼異味上,而非代碼異味對軟件的影響[5].

重構(gòu)可以幫助改進(jìn)軟件設(shè)計,使軟件更容易理解,幫助開發(fā)人員發(fā)現(xiàn)bug并提高開發(fā)效率[2].針對手工重構(gòu)存在容易引入錯誤的問題,劉偉等人提出了一種以單例模式為導(dǎo)向的源代碼自動重構(gòu)方法,通過將源代碼轉(zhuǎn)換成抽象語法樹并進(jìn)行操作的方式,成功實(shí)現(xiàn)了單例化重構(gòu)[6].Monteiro和Fernandes提供了一組面向切面編程(AOP)風(fēng)格代碼的重構(gòu)和代碼異味特征,并且還提供了一組特定的AOP的重構(gòu)[7].Hamaz提出了一種基于對代碼異味之間依賴關(guān)系的定量分析的方法,指出有些代碼異味需要更多的補(bǔ)救修復(fù)工作,并且在重構(gòu)過程中開發(fā)人員應(yīng)給予必要的關(guān)注[8].另外,他們的文章中還介紹了Kerievsky和Fowler提出的代碼異味之間的區(qū)別.但在項目的提交中,一些開發(fā)人員明確承認(rèn)的重構(gòu)卻很少被研究.

2.2 代碼異味檢測方法與工具

在代碼異味數(shù)量龐大的情況下,手動檢測代碼異味是低效的.此外,它嚴(yán)重依賴于開發(fā)人員的經(jīng)驗(yàn),缺乏相關(guān)的經(jīng)驗(yàn)可能導(dǎo)致檢測的混亂[9].而各種檢測代碼異味的方法和工具可以進(jìn)行良好的檢測工作.一些工具已經(jīng)被應(yīng)用到軟件開發(fā)的實(shí)踐中.其中,Klockwork、PMD和FindBugs是典型的用來檢測潛在代碼缺陷(檢測包括:命名缺陷和未使用的代碼)和代碼異味(例如:長方法和上帝類等)的工具.

需要指出的是,代碼異味一般產(chǎn)生在代碼的升級過程中產(chǎn)生.林濤等人總結(jié)了代碼異味面臨的兩個問題:1)類型難以劃分；2)難以量化.他們對4種代碼異味進(jìn)行了量化研究,并提出了面向代碼異味的“容器-破壞者-發(fā)現(xiàn)者”檢測策略.將人工免疫基本概念和信號遷移至軟件工程,檢測結(jié)果優(yōu)良[10].

2.3 自承認(rèn)現(xiàn)象的研究

自承認(rèn)現(xiàn)象的研究,在技術(shù)債務(wù)研究領(lǐng)域比較流行.Potdar和Shihab對自承認(rèn)技術(shù)債務(wù)(Self-admitted technical debt)進(jìn)行了探索性研究,發(fā)現(xiàn)在2.4%的文件中存在自承認(rèn)技術(shù)債務(wù),而26.3%～63.5%的自承認(rèn)技術(shù)債務(wù)在引入后會被清除[11].

Gabriele Bavota 等人,針對Potdar的論文進(jìn)行了深入的分析,通過對159個軟件的自承認(rèn)技術(shù)債務(wù)的演變與擴(kuò)散的檢驗(yàn)中得出以下幾點(diǎn)結(jié)論:1)自承認(rèn)技術(shù)債務(wù)普遍存在的；2)技術(shù)債務(wù)主要表現(xiàn)為代碼,缺陷以及需求債務(wù)；3)在開發(fā)者沒有修復(fù)的情況下會隨時間增加；4)即使修復(fù),也會在系統(tǒng)存活很長時間[12].Maldonado等人利用自然語言處理的方法,通過對源注釋的自動識別來挖掘自承認(rèn)技術(shù)債務(wù),研究表明即使在一個相對較小的訓(xùn)練數(shù)據(jù)集下也具有良好的準(zhǔn)確率[13].Sultan Wehaibi等人就自承認(rèn)技術(shù)債務(wù)對軟件質(zhì)量的影響方面進(jìn)行了進(jìn)一步探索,通過對開源項目進(jìn)行了案例研究后發(fā)現(xiàn),自承認(rèn)技術(shù)債務(wù)比非自承認(rèn)技術(shù)債務(wù)要引入更少的代碼缺陷,技術(shù)債務(wù)不僅可能產(chǎn)生代碼缺陷的影響,而且會令系統(tǒng)難以適應(yīng)未來的變化[14].

在軟件重構(gòu)與自承認(rèn)技術(shù)債務(wù)相關(guān)研究的啟發(fā)下,我們將類似的概念遷移到探索自承認(rèn)重構(gòu)(SAR)的方向上,使用代碼異味作為代碼質(zhì)量的度量指標(biāo),來驗(yàn)證在SAR版本中代碼質(zhì)量是否得到了改善.關(guān)于SAR的研究結(jié)果將有助于開發(fā)者了解代碼的狀況以及軟件的質(zhì)量,并提示開發(fā)人員改善項目.

3 研究設(shè)計

我們對一個托管在GitHub上的大型Java開源軟件項目(Open source software,簡稱OSS)進(jìn)行案例研究.在本節(jié)中,我們將根據(jù)Runeson和H?st提出的指導(dǎo)原則[15]來設(shè)計和描述本文的案例研究.

3.1 目標(biāo)與研究問題

本案例研究的目標(biāo)是:利用“目標(biāo)-問題-度量”方法[16],在開源項目環(huán)境中,分析SAR對源代碼的影響,并驗(yàn)證其提高代碼可維護(hù)性的有效性.基于上述目標(biāo),我們提出四個主要研究問題(RQs):

RQ1:SAR改善了源代碼的結(jié)構(gòu)質(zhì)量嗎?

重構(gòu)的目的在于提高軟件的內(nèi)部質(zhì)量[2],因此,我們想探究在SAR版本中源代碼的質(zhì)量是否有所提高.這個RQ可以分解為以下三個子問題進(jìn)行細(xì)化研究：

RQ1.1:SAR減少了代碼異味嗎?如果是,哪些代碼異味最容易減少?

代碼異味是被廣泛接受的衡量源代碼質(zhì)量的指標(biāo)[2].因此,研究SAR是否減少了代碼異味將是評估代碼質(zhì)量的關(guān)鍵.如果答案是肯定的,那么接下來我們想知道哪些代碼異味會在SAR版本中減少.

RQ1.2:與非SAR版本相比,SAR版本是否具有更少的代碼異味?

代碼異味的數(shù)量可以在一定程度上反映軟件系統(tǒng)的結(jié)構(gòu)質(zhì)量.所以,SAR中的代碼異味是否少于非SAR是一個值得研究的問題.

RQ1.3:在SAR中,代碼異味的嚴(yán)重級別的分布情況是怎樣的?

代碼異味檢測工具提供了代碼異味的嚴(yán)重級別,其代表著代碼異味的嚴(yán)重程度和修復(fù)的優(yōu)先等級.在SAR中,代碼異味嚴(yán)重程度的分布可以用來評估代碼的總體質(zhì)量狀態(tài).

RQ2:SAR和非SAR版本之中修改文件的數(shù)量有明顯區(qū)別嗎? 被修改文件的數(shù)量與SAR中新引入的代碼異味的數(shù)量具有相關(guān)性嗎?

在軟件開發(fā)過程中,每一次提交都涉及到不同數(shù)量的源文件的修改,因此被修改的文件數(shù)量和SAR中引入的代碼異味數(shù)量之間的關(guān)系是一個值得探索的問題.

RQ3:是否有開發(fā)者傾向于自承認(rèn)重構(gòu)?

不同的開發(fā)者有不同的代碼風(fēng)格和代碼理解能力.自承認(rèn)重構(gòu)信息是基于自然語言基礎(chǔ)上的,因此SAR是否與開發(fā)者的經(jīng)驗(yàn)、寫作風(fēng)格或者提交次數(shù)有關(guān)系,是研究SAR現(xiàn)象的關(guān)鍵.

RQ4:在項目開發(fā)的生命周期中,SAR是如何分布的?

SAR分布是否平衡反映著軟件項目開發(fā)周期中的自承認(rèn)重構(gòu)狀態(tài),了解SAR分布對我們了解整體軟件生命周期狀態(tài)將有所幫助和啟發(fā).

3.2 案例選取

本研究主要探索SAR現(xiàn)象,因此以SAR作為分析單元.我們將采用以下標(biāo)準(zhǔn)對案例進(jìn)行選取:

·所選項目應(yīng)具有兩年以上的歷史.

·所選項目主要開發(fā)語言為Java.PMD是被廣泛用于檢測代碼異味的工具,本案例分析中,我們將使用PMD來檢測代碼異味.我們希望利用PMD的eclipse插件,從而所選項目應(yīng)為Java編寫.

·所選項目擁有至少20個SAR.SAR越多意味著擁有越多可以用于案例分析研究的數(shù)據(jù),而相對較少的SAR可能會導(dǎo)致結(jié)論的局限.

·所選項目的開發(fā)開發(fā)者數(shù)目需超過10個.

·項目的源代碼應(yīng)該有良好的注釋(高可讀性和可分析性),以便于數(shù)據(jù)分析.

·項目完整的提交數(shù)據(jù)列表可以由TortoiseGit客戶端導(dǎo)出.

3.3 數(shù)據(jù)收集過程

3.3.1 需收集的數(shù)據(jù)

為了回答第3.1節(jié)中定義的RQs,表1中列出了我們需要收集的數(shù)據(jù)項,也列出了每個數(shù)據(jù)項對應(yīng)的目標(biāo)RQ(s).

3.3.2 數(shù)據(jù)收集方法

圖1顯示了SAR的收集過程.對于選定的項目我們執(zhí)行以下步驟:

1)下載代碼存儲庫——從GitHub下載項目代碼庫.

2)導(dǎo)出提交記錄——使用TortoiseGit客戶端導(dǎo)出項目的提交記錄.

3)識別候選SAR——根據(jù)SAR的定義,識別SAR的一種方法是在選定的項目提交信息中搜索“refactor ”的關(guān)鍵字.輸出則是一組候選SAR版本信息.

4)手動檢查候選SAR——檢查每個候選SAR提交信息,以排除錯誤情況.例如:開發(fā)人員可能會寫“going to refactor”、“not refactor”等,在這種情況下,是沒有重構(gòu)發(fā)生的.因此,我們需要手動檢查每個候選SAR版本,排除錯誤識別.

5)記錄SAR的提交——記錄SAR相關(guān)的提交信息,包含修訂號和開發(fā)者等.

表1 需收集的數(shù)據(jù)項

3.3.3 非SAR版本收集

為了回答RQ1.2,對于所選定的項目,我們還需要收集不包含SAR的普通提交版本用來做對比實(shí)驗(yàn).我們稱之為非SAR.在選取的過程中,我們采用了隨機(jī)選擇的方式,并要求保證非SAR集合的版本數(shù)量與SAR集合的版本數(shù)量保持一致,以排除數(shù)量因素的干擾.

圖1 SAR收集過程

3.3.4 代碼異味收集

我們使用靜態(tài)檢測的方法來識別代碼異味.作為廣為使用的檢測方法,靜態(tài)代碼嗅探方法通過多種方式測量并分析代碼是否違反了特定的質(zhì)量規(guī)則(例如:coupling metrics).許多工具都采用了靜態(tài)嗅探的檢測方法,例如廣泛使用的代碼異味檢測工具PMD.

在PMD檢測工具中有33個規(guī)則集和237條檢測規(guī)則(如:圈復(fù)雜度和松耦合).在本文案例研究中,在下載了所選項目的代碼存儲庫后,將會對每個SAR對應(yīng)的代碼庫版本導(dǎo)出.隨后,我們將分析每個SAR對應(yīng)版本的源文件,以及它上一個版本的源文件,以獲得兩個代碼庫版本的源文件之間代碼異味分析報告的差異.圖2顯示了代碼異味收集的過程.對于每一個SAR版本與非SAR版本,我們都執(zhí)行以下步驟:

圖2 Code smell的收集過程

1)導(dǎo)出源代碼所需版本——導(dǎo)出目標(biāo)版本(V1),以及它的前一次提交版本(V2).

2)檢測代碼異味——使用PMD插件來檢測V1和V2中的代碼異味.PMD插件生成代碼異味檢測報告.

3)導(dǎo)出代碼異味報告——導(dǎo)出上一步生成的代碼異味檢測報告.

4)識別代碼異味報告中的差異——比較V1和V2的代碼異味報告,確定報告之間代碼異味的差異.

3.3.5 數(shù)據(jù)分析方法

為了回答第3.1節(jié)提出的研究問題,我們需要收集SAR代碼異味數(shù)據(jù).根據(jù)表1規(guī)定的收集的數(shù)據(jù)項.我們將針對不同的RQ,采取不同的數(shù)據(jù)分析方法.本文中所有的數(shù)據(jù)搜集過程,我們都編寫了實(shí)驗(yàn)程序*https://github.com/vicotorz/PMDlet.

對于RQ1.1、RQ1.2和RQ3,只需使用描述性統(tǒng)計.具體地,針對RQ1.1,我們將收集SAR項目中的代碼異味數(shù)量(NCS)和代碼異味變化量(DNCS),重點(diǎn)對代碼異味的增減情況進(jìn)行統(tǒng)計,并計算代碼異味增加、不增加、減少代碼的項目版本比例,結(jié)合代碼異味數(shù)量,來確定SAR項目中代碼異味的具體情況.RQ1.2中我們將引入同等數(shù)量的非SAR版本與SAR版本進(jìn)行參照對比實(shí)驗(yàn),利用代碼異味變化量(DNCS)驗(yàn)證代碼異味在自承認(rèn)與非自承認(rèn)重構(gòu)版本中的差別.RQ1.3中,我們將對SAR版本中檢測到的代碼異味級別進(jìn)行數(shù)據(jù)統(tǒng)計,并分析各種代碼異味級別的占比,用以評估SAR版本中的代碼異味級別分布,以及代碼質(zhì)量情況.

對于RQ2,我們將對代碼異味變化量(DNCS)和修改的源代碼數(shù)量(NMF)的相關(guān)系數(shù).即利用Pearson計算了兩個變量之間的相關(guān)系數(shù)[17],用以確定兩者的關(guān)聯(lián)關(guān)系.

為了回答RQ3,將會統(tǒng)計所有參與開發(fā)項目的開發(fā)者作者信息,以及有關(guān)SAR作者信息(包括用戶名,郵件,提交次數(shù),SAR提交次數(shù)).計算SAR開發(fā)者所占的數(shù)量SAR作者在軟件開發(fā)過程中自承認(rèn)重構(gòu)對應(yīng)的比例.

對于RQ4,利用已收集的SAR信息,進(jìn)行位置標(biāo)注,用Matlab程序?qū)AR分布進(jìn)了圖形描述.以確認(rèn)和總觀SAR在項目周期中的分布特點(diǎn).表2概括總結(jié)了分析的方法.

需要指出的是,在實(shí)驗(yàn)過程中,PMD默認(rèn)規(guī)則集中有許多并不適合我們案例分析的代碼異味.例如,“LocalVariableCouldBeFinal”表示將局部變量轉(zhuǎn)換為final的代碼異味的建議,這種代碼異味經(jīng)常發(fā)生且粒度太小.因此我們從PMD所能檢測的代碼異味集合中選擇一些關(guān)鍵代碼異味.在選取過程中,我們由兩組人員分析了PMD提供的代碼異味規(guī)則描述,綜合選擇了規(guī)則語句中包含單詞“maintainability”、“readability”和與可維護(hù)性相關(guān)的代碼異味.如表3中展示了一些被PMD檢測到的代碼異味.

表2 數(shù)據(jù)分析方法

為了測試SAR對代碼質(zhì)量的影響,需要與非SAR版本進(jìn)行比較.但非SAR的數(shù)量遠(yuǎn)遠(yuǎn)超過SAR的版本數(shù)量,由于數(shù)目龐大,測試所有非SAR不僅會很耗時,同時也引入了數(shù)量不確定性因素,因此我們隨機(jī)選擇了與SAR版本數(shù)量相等的非SAR版本.

表3 PMD規(guī)則

4 研究結(jié)果

4.1 所選項目

本文中,我們選擇了一個大型的開源軟件項目用作為案例分析,即Fastjson*https://github.com/alibaba/fastjson.Fastjson是一個java庫,用來將java對象轉(zhuǎn)換成json格式,也可以將json字符串轉(zhuǎn)換為等效的java對象.Fastjson作為一種流行的開源項目,廣泛應(yīng)用于許多軟件項目中.表4列出了Fastjson項目信息.

表4 項目統(tǒng)計信息

4.2 結(jié)果

4.2.1 代碼質(zhì)量的影響(RQ1)

RQ1.1:表5列出了在SAR版本中不同的代碼異味狀況.如表5所示,70.25%(85/121)的SAR版本沒有增加代碼異味.

表5 DNCS信息

我們在表6中列出了最容易減少的前5類代碼異味.在所有類型的代碼異味中,DataflowAnomalyAnalysis是最常被減少的.并且這種類型的代碼異味,在SAR版本中出現(xiàn)最多.接下來,我們對表6中所列出的5種代碼異味進(jìn)行簡要介紹:

表6 變化最大的前5名代碼異味

·數(shù)據(jù)流異常分析(Dataflow Anomaly Analysis):1)已定義的變量為初始化；2)變量定義后僅在某個分支中使用；3)已賦值的變量在未使用的情況下重新賦值.

·松耦合(Loose Coupling):使用實(shí)現(xiàn)類型作為對象引用,限制了適用范圍以及靈活性.

·未使用的引入(Unused Imports):未使用的imports包.

·秩復(fù)雜性(Cyclomatic Complexity):圈復(fù)雜度,表現(xiàn)在獨(dú)立可行的路勁條數(shù),數(shù)值越大表示判斷邏輯復(fù)雜.

·具體聲明異常(Signature Declare Throws Exception):不確定方法中拋出的具體異常.

RQ1.2:在本文的案例研究中,有121個SAR版本與121個隨機(jī)的非SAR版本.如表7所示,在非SAR版本中,代碼異味增加(DNCS>0),保持不變(DNCS=0),減少(DNCS<0)的情況分別為76、29和16.而在SAR版本中,代碼異味的數(shù)量增加(DNCS>0),保持不變(DNCS=0),減少(DNCS<0),分別為36、39和46.37.19%(45/121)的非SAR版本中沒有增加代碼的異味,而70.25%(85/121)的SAR版本中代碼異味沒有增加.這意味著,與非SAR版本相比,SAR更傾向于不增加Fastjson中的代碼異味.

RQ1.3:PMD可以檢測237種代碼異味.其中定義了每個代碼異味的嚴(yán)重級別(使用1-5來表示),分別為:Error High、Error、Warning High、Warning和Information.表7展示了PMD標(biāo)識的代碼異味的默認(rèn)的嚴(yán)重級別的分布.#(PMD code smell type)表示PMD中定義的相應(yīng)嚴(yán)重級別的代碼異味數(shù)量.DNCS定義為SAR中代碼異味數(shù)量的增量.#(PMD code smell)表示PMD在項目中實(shí)際檢測到的代碼異味嚴(yán)重級別的數(shù)量.#(Detected code smell type)是實(shí)際檢測到的代碼異味類型的數(shù)量.類型比例表示PMD可以檢測到的代碼異味類型占所有代碼異味類型的比例.

表7 代碼異味的變化量

如表8所示,在Fastjson的所有SAR版本中,存在著131個嚴(yán)重級別為“Information”的代碼異味,引入了8個嚴(yán)重級別為“Error”的代碼異味;減少了20個嚴(yán)重級別為 “Warning”、327 個嚴(yán)重級別為“Warning High”及17個嚴(yán)重級別為“Error High”的代碼異味.

表8 代碼異味嚴(yán)重級別分布

4.2.2 被修改的源文件數(shù)量與引進(jìn)代碼異味數(shù)量的關(guān)系(RQ2)

表9顯示了SAR和非SAR中被修改的源文件數(shù)量(NMF)的平均值.總體來講,平均每個SAR中被修改的源文件數(shù)量(41)比非SAR(66)要少.

表9 NMF 分布

我們利用Pearson相關(guān)性研究了NMF與新引入的代碼異味(DNCS>0)之間的關(guān)系.如表10所示,被修改的源文件的數(shù)量與新引入代碼異味數(shù)量的顯著性水平為α= 0.01,呈顯著相關(guān)關(guān)系.

表10 相關(guān)性結(jié)果

4.2.3 有關(guān)SAR開發(fā)者(RQ3)

并不是所有開發(fā)者在軟件開發(fā)過程中都具有自承認(rèn)重構(gòu)行為.在分析了Fastjson的提交信息之后,我們發(fā)現(xiàn)特定的開發(fā)者具有SAR行為傾向.表11顯示了在項目中執(zhí)行SAR的開發(fā)者信息.FSC指參與項目的總開發(fā)人員數(shù)量、SAR開發(fā)者代表自承認(rèn)重構(gòu)的提交總?cè)藬?shù).

表11 開發(fā)者信息

圖3展示了每個SAR開發(fā)者所產(chǎn)生的SAR的數(shù)量.其中有大量使用了不同網(wǎng)絡(luò)身份的開發(fā)者.我們通過身份語義、郵箱等關(guān)鍵信息分析并合并了不同的網(wǎng)絡(luò)身份,最后產(chǎn)生了3個SAR開發(fā)者的合并集合.結(jié)果顯示,提交人3在Fastjson項目中執(zhí)行了大部分(108/121)的自承認(rèn)重構(gòu).

圖3 開發(fā)者SAR數(shù)量

此外,我們計算了SAR開發(fā)者自承認(rèn)件重構(gòu)次數(shù)占其自身提交總次數(shù)的比例,結(jié)果如表12所示,每個SAR開發(fā)者的僅有不超過20%的SAR行為.

表12 SAR開發(fā)者的SAR比例

4.2.4 自承認(rèn)重構(gòu)分布(RQ4)

圖4展示了SAR對應(yīng)的代碼庫版本(RSAR)的分布情況.每條線代表一次SAR的出現(xiàn).如圖4所示,深色粗線條的部分具有較高的SAR密度.

圖4 Fastjson的SAR分布

5 討 論

5.1 研究結(jié)果分析

RQ1:如表5和表7所示,并非所有的SAR都能提高代碼的質(zhì)量.在SAR版本中,傾向于不增加項目的代碼異味,也就意味著總體上SAR中的代碼異味會減少,代碼質(zhì)量會得到改善.這與開發(fā)者提高代碼的可維護(hù)性的重構(gòu)意圖相吻合.事實(shí)上,29.75%的SAR(總共121個SAR中的36個)引入了新的代碼異味.從SAR和非SAR兩個數(shù)據(jù)集的比較結(jié)果可以看出,有37.19%的非SAR版本和70.25%的SAR版本沒有增加代碼異味,這意味著SAR引入的代碼異味比非SAR引入的要少.DataflowAnomalyAnalysis是發(fā)生和變化最頻繁的代碼異味.在使用PMD進(jìn)行案例分析的過程中,前兩類代碼異味數(shù)量偏大可能是由于它們對應(yīng)的PMD代碼異味檢測規(guī)則粒度太小導(dǎo)致的.

如表8所示,實(shí)際檢測的代碼異味嚴(yán)重級別包括了PMD中定義的所有嚴(yán)重級別類型.42.86%的代碼有“Error High”嚴(yán)重級別.在所有檢測到的代碼異味中,嚴(yán)重級別為“Error High”的代碼異味數(shù)量最大,這意味著被研究項目的代碼質(zhì)量一般.導(dǎo)致這種結(jié)果的原因可能是由于預(yù)定義代碼異味類型的數(shù)量不平衡,規(guī)定的大部分代碼異味類型嚴(yán)重級別為“Warning High”(見表7)所致.另外,出現(xiàn)的“Error”高嚴(yán)重級別的代碼異味是一種代碼質(zhì)量下滑的信號,應(yīng)該特別注意.

RQ2:在SAR中,被修改的源文件數(shù)量與新引入的代碼異味數(shù)量之間存在顯著正相關(guān).我們通讀了所有的SAR版本提交信息,發(fā)現(xiàn)Git的重命名、添加和刪除操作將導(dǎo)致了代碼異味的增多.因此,Git中的特定操作與代碼異味之間的關(guān)系可以進(jìn)行更深入的研究.

RQ3:如表12所示,我們可以看到只有6.25%的開發(fā)者在提交記錄中自承認(rèn)軟件重構(gòu).在SAR開發(fā)者的提交記錄中,SAR的提交次數(shù)所占的比例也是較小的.

RQ4:自承認(rèn)重構(gòu)行為大部分發(fā)生在了Fastjson的開發(fā)初期與中期,這表示在項目開發(fā)生命周期中的不成熟階段,即頻繁進(jìn)行質(zhì)量改進(jìn)活動.

5.2 啟發(fā)性信息

代碼異味的增多意味著項目質(zhì)量的下降,在對Fastjson的研究過程中,SAR通常是代碼質(zhì)量改進(jìn)的積極信號.然而一些SAR版本中會存在代碼質(zhì)量下降的情況,原因可能是SAR版本中沒有發(fā)生真正的重構(gòu).

在本文的案例研究中,被修改的源文件數(shù)量與新引入的代碼異味數(shù)量存在顯著的正相關(guān)關(guān)系,這意味著開發(fā)人員對源文件增加,刪除,重命名,修改等操作對代碼異味的變化有著直接的影響.另外,值得指出的是,開發(fā)者在開發(fā)過程中需要注意代碼規(guī)范.

SAR表明了開發(fā)人員對代碼質(zhì)量改進(jìn)的認(rèn)識,因?yàn)殚_發(fā)人員明確地宣稱了重構(gòu),在某種程度上表明了他們進(jìn)行代碼結(jié)構(gòu)質(zhì)量改進(jìn)的意愿.SAR的作用除了標(biāo)記重構(gòu)信息,記錄版本更新以外,在多人協(xié)同開發(fā)過程中,也為接下來他人接替代碼項目起到了提示作用.

值得一提的是,在本文的研究過程中,發(fā)現(xiàn)了很多一些殘缺,意義模糊的提交信息,因此,在協(xié)同開發(fā)過程中,規(guī)范格式的提交信息(包括修改說明)是有必要值得實(shí)踐的.

5.3 有效性威脅

本案例分析的結(jié)果有效性存在著以下兩點(diǎn)潛在威脅:首先,PMD工具中可能潛在著代碼異味檢測的不準(zhǔn)確.考慮到PMD被廣泛應(yīng)用于工業(yè),我們認(rèn)為PMD是可靠的,因此這種威脅是有限的.其次,本案例研究中只選擇了一個大型的Java開源項目,因此我們不能斷言,本案例研究中關(guān)于SAR的結(jié)論適用于閉源軟件系統(tǒng)和用其它編程語言編寫的軟件項目.

6 總 結(jié)

以往研究中很少有針對SAR現(xiàn)象的研究.本文中我們從多個角度探討了自承認(rèn)重構(gòu)(SAR)現(xiàn)象,經(jīng)過對Fastjson項目進(jìn)行案例分析,得到如下結(jié)果:1)雖然小部分的SAR引入了新的代碼異味,但總體上SAR往往是代碼質(zhì)量提高的信號；2)DataflowAnomalyAnalysis是Fastjson項目中SAR中最常發(fā)生和減少的代碼異味類型；3)平均來講,SAR引入的代碼異味數(shù)量比非SAR引入的代碼異味數(shù)量少；4)SAR版本中,大多數(shù)代碼異味的嚴(yán)重級別為 “Warning High”,而嚴(yán)重級別為“Error”的代碼異味只占小部分；5)在SAR中,被修改的源文件數(shù)量與新引入的代碼異味數(shù)量呈正相關(guān)關(guān)系；6)進(jìn)行過SAR的開發(fā)者占所有開發(fā)者的比例較?。?)在Fastjson項目開發(fā)生命周期的初期和中期,SAR的發(fā)生頻率較高.

正如我們看到的,自承認(rèn)重構(gòu)總體上提高了代碼質(zhì)量.在本文有關(guān)SAR的案例研究中,有很多可以切入并深入研究細(xì)節(jié),未來我們對SAR的研究將側(cè)重于以下幾個方面:

·SAR與自承認(rèn)技術(shù)債務(wù)的關(guān)系.自承認(rèn)技術(shù)債務(wù)往往是開發(fā)者特意為之,需要有計劃地通過重構(gòu)來進(jìn)行償還.自承認(rèn)技術(shù)債務(wù)與SAR的關(guān)系,自承認(rèn)技術(shù)債務(wù)和SAR是如何來共同影響軟件代碼質(zhì)量和軟件的可維護(hù)性的,都值得下一步深入研究.

·更多案例的SAR分析.SAR在不同的項目上,表現(xiàn)可能會有所不同.我們將對不同應(yīng)用領(lǐng)域中的更多的軟件項目上進(jìn)行本文案例分析的重復(fù)性研究,探索是否得到關(guān)于SAR的共性結(jié)論.

·SAR密度.SAR的分布提供了有價值的重構(gòu)提交信息,同時,SAR密度可以更好地了解代碼歷史和演化,評估代碼狀態(tài).

·SAR動機(jī).不同的SAR具有不同的動機(jī),研究背后的深層原因會讓我們對SAR有更深的認(rèn)識與理解.

·細(xì)化SAR的劃分.在本文中,我們利用關(guān)鍵字搜索的方式簡單地對SAR進(jìn)行了挑選,然而事實(shí)上,自承認(rèn)重構(gòu)的表現(xiàn)復(fù)雜,比如關(guān)鍵字Move Method等,原則上也應(yīng)該劃分為SAR.我們可以利用數(shù)據(jù)挖掘的方式深入進(jìn)行SAR的識別工作.