代碼壞味對軟件演化影響的實證研究?

章曉芳,朱 燦

(蘇州大學 計算機科學與技術學院,江蘇 蘇州 215006)

代碼壞味(code smell)通常代表不良的程序設計,會對程序理解與軟件維護產生不良影響[1].

例如ClassDataShouldBePrivate這種壞味,暴露了類中的字段,違反了封裝原則.為了減輕壞味對軟件開發及演化的影響,近年來,研究者們對代碼壞味進行了多方面的研究,包括代碼壞味與開發者之間存在的關聯[2]、代碼壞味的演化[3-5]、壞味對代碼理解與維護的影響[5,6]、壞味與源文件的變化傾向(change-proneness)及出錯傾向(fault-proneness)之間的關系[1,7]等.

為幫助開發人員識別出存在于不同軟件中的代碼壞味,研究者們已經設計并實現了多種自動檢測壞味的工具.這些工具基于多種分析技術,可以幫助識別不同語言的程序中存在的壞味[8-12].然而,即使這些工具可以相對準確并充分地檢測出多種壞味,大多數的實證研究也僅僅局限在對軟件已發布的單個版本進行探究.事實上,軟件演化已經被認為是引起軟件復雜度逐漸增加的重要因素之一[13,14].在演化過程中,軟件開發人員對源文件的操作則是代碼壞味在軟件生命周期中演化的根本原因[15,16].基于此現狀,充分了解軟件源文件的操作與代碼壞味變化之間的關聯,將會有助于開發人員提升代碼的設計、保證代碼的質量.因此,本文系統地開展了一個詳細的實證研究,以尋求存在于代碼壞味與源文件操作之間的相互關聯.具體來說,將源文件的改變細化為 3類最基本的操作:增加新文件、修改已有文件與移除無用文件.本文使用了廣泛應用的壞味檢測工具DéCOR[17]來檢測13種最常見的代碼壞味,對8個Java項目共104個版本進行了有關源文件操作與代碼壞味之間關聯性的實證研究.

通過實證研究,本文得到如下結論:首先,隨著版本的演化,含有壞味的文件在所有文件中的占比在不同的項目中呈現出不同的變化趨勢,而在所有研究項目中,含有壞味的文件會發生改變的概率均較低;其次,含有代碼壞味的文件在 3類具體操作中更傾向于被修改,而文件的添加、刪除操作則與代碼壞味并沒有很大的關聯;進一步地,如果文件中包含 ComplexClass和 LongParameterList這兩種壞味,源文件將會有很大的被修改傾向,另外,AntiSingleton、Blob和ClassDataShouldBePrivate這幾種壞味也會在一定程度上對文件的修改產生影響;最后,包含ComplexClass和LongParameterList這兩種壞味的文件有較大的重疊,且包含這兩種壞味的文件有較大的可能性包含其他類型的壞味.

1 背景與相關工作

1.1 代碼壞味

有關代碼壞味的研究一直是軟件維護領域的熱點之一.Fowler[18]首次提出“壞味”的概念,共描述了22種在軟件發展與維護過程中存在設計缺陷的特殊代碼結構.為了幫助開發者與研究者們識別代碼壞味,很多研究人員致力于對壞味進行檢測與等級劃分[19-23],并對代碼壞味的處理順序給出了建議[24].在工具方面,Moha等人[17]提出的DéCOR工具運用DETEX框架自動將壞味的定義轉換為壞味檢測,該工具已被廣泛地運用在已有的代碼壞味的研究中[25].

在壞味檢測過程中,盡管已有多種壞味被定義,但其中有 13種壞味被認為對軟件質量有著重要的影響[26],因此,本文使用DéCOR工具對這13種壞味進行檢測,表1給出了這13種壞味的具體描述及其簡稱.

Table 1 Description of code smells表1 代碼壞味的描述

Table 1 Description of code smells (Continued)表1 代碼壞味的描述(續)

1.2 代碼壞味影響的實證研究

為探究代碼壞味與軟件演化之間的關系,Chatzigeorgiou等人[27]研究了存在于面向對象程序中壞味的演化,并發現對于大多數的研究實例而言,壞味持久地存在于軟件的發展與演化過程中.Olbrich等人[4]則具體針對GodClass和 ShotgunSurgery這兩種壞味進行研究,研究表明,壞味的演化存在著不同的階段、多樣的改變頻率與不同的改變規模.本文的研究不僅僅關注于壞味隨著軟件的演化呈現出的變化趨勢,而是更深入地探究代碼壞味是否與文件的添加、修改、刪除這3類最基本的文件操作之間存在著某種程度上的相互關聯.

針對代碼壞味產生的原因,Tufano等人[28]進行了一個大規模的實證研究,來了解代碼壞味何時會被引入以及為什么被引入.該研究通過統計壞味被引入之前源碼文件被提交的次數,發現這些壞味通常在源碼剛剛被添加到項目中時就被引入.另外,通過分析提交源碼的目的、所屬項目和開發者當時所處的狀態,該研究試圖更進一步地探究壞味被引入的原因.研究表明,在軟件開發過程中,為增強軟件現有的功能或增加新的功能時,開發人員往往更容易引入代碼壞味.受到該研究的啟發,本文將進一步探究是否所有被添加的源文件都和壞味存在著明顯的相互關聯.因此,對于每一個研究項目版本,將所有添加進這個版本的文件作為研究對象之一;同時,作為文件基本操作的修改與刪除,也是本文的重點研究對象.

代碼壞味的存在往往給軟件的發展與演化帶來一定的阻礙.Khomh等人[26]探究了壞味與代碼變更及代碼錯誤傾向之間的相互關聯.該研究表明,在幾乎所有被研究的項目版本中,包含壞味的源碼比不含壞味的源碼有著更易發生改變或是發生錯誤的傾向.同時,該研究也探討了一些具體類型的壞味是否有更大的傾向發生錯誤或被修改.在此基礎上,Palomba等人[29]開展了更大規模的實證研究,探究了代碼壞味的分布及其對軟件維護的影響.與上述研究不同的是,為了更好地了解代碼壞味產生的影響,本文將發生改變的源碼文件類型更細致地劃分為新增、被修改與被移除的文件,從而分別探究這些最基本的文件操作與壞味之間的相互關聯.

我們在前期的研究工作中[30,31]探討了代碼壞味與錯誤傾向之間的相互關聯,在研究過程中發現,軟件的演化實際上將細化為各個版本之間的文件變更,繼而開始研究代碼壞味與文件變更之間的關聯.在此基礎上,本文針對8個開源項目的共計104個版本開展了更大規模的實證研究,力求能進一步驗證、擴充前期研究的結論,并深入探討代碼壞味與軟件演化的關系,包括代碼壞味與源文件操作的關系、壞味文件之間的相互關系等.

除了上述有關代碼壞味對軟件自身影響的相關研究,研究者們還關注到開發者們如何應對軟件中存在的代碼壞味[2],例如通過開發人員的具體行為來探尋壞味存在的生命周期等[15].

2 實證研究

2.1 預定義

本文的實證研究致力于在文件級別上探究代碼壞味與軟件演化之間存在的關聯,其中,我們將軟件的演化具體為文件的添加、修改與移除操作.為了方便解釋,我們首先給出一些相關定義如下.

定義1.項目P={Vi|i=1,…,n},Vi表示項目P中的第i個發布版本.

定義2.令存在于第i個版本中而不存在于第i-1版本中的文件為版本i的新增文件(added file),記為Ai;令在版本之間發生修改且同時存在于兩版本之間的文件為被修改文件(modified file),記為Mi;令存在于第i個版本而不存在于第i+1個版本中的文件為被移除文件(removed file),記為Ri.令新增文件、被修改文件與被移除文件的合集為發生改變的文件,記為Ci.

定義 3.第i個版本中,令所有包含壞味的文件為壞味文件,記為Si;令所有不含壞味的文件為非壞味文件,記為Ni;令版本中所有的Java文件為Allfilesi.

定義4.第i個版本中,令含有壞味的文件在所有文件中的占比為壞味密度(smell density),計算方法如下.

定義5.第i個版本中,令含有壞味的文件發生變更的概率為壞味活躍度(smell activity),計算方法如下.

由定義4、定義5可見,活躍度的值反映了壞味文件在軟件演化過程中發生改變的概率,通過計算壞味密度與壞味活躍度的值,將有助于分析壞味對軟件演化的影響.

定義6.第i個版本中,令ChangeType指代新增、被修改和被移除這3種不同的文件變化類型,分別計算發生這3種不同類型改變的壞味文件在所有壞味文件中的占比以及發生改變的非壞味文件在所有非壞味文件中的占比,計算方法如下.

定義7.令包含某具體壞味的文件為smellm,不包含此類壞味的文件記為non-smellm.第i個版本中,通過獲得包含該種壞味的文件與發生某種變化類型文件的交集,再除以包含此壞味文件的數量,可以得到包含此種壞味的文件發生該變化類型的占比.類似地,可以獲得不包含此壞味的文件發生各類變化的占比,計算公式如下.

定義8.第i個版本中,令兩種不同壞味文件的重疊率為包含壞味smellm,smelln的文件分別在包含這兩種壞味的文件中占比,計算方法如下.

2.2 研究問題

代碼壞味隨著軟件項目的演化不斷變化,一方面已有研究者表明,新增文件有很大的可能性會引入低質量甚至是錯誤的代碼[28],因此隨著軟件項目規模的擴大,含有代碼壞味的文件數量也會隨之上升;而另一方面,代碼重構也是提升軟件項目可維護性的關鍵因素,在演化的過程中,開發者們往往會重構一些不好的程序設計,從而減少了含有代碼壞味的文件數量[6].由此可見,代碼壞味的密度可能會隨著軟件的演化呈現波動的狀態.

壞味密度和壞味活躍度可以為開發人員提供重要的信息來做出開發過程中的關鍵決定,例如他們何時需要重構代碼設計以及哪一部分代碼需要被重構,又或者通過這些信息來判斷軟件項目是否達到了成熟階段等.進一步地,本文分析壞味與文件改變之間的相互關聯,有助于為軟件項目的維護做出更好的重構計劃.此外,不同的壞味可能存在于同一個的文件中,被不同壞味影響的文件是否存在較大的重疊,了解這樣的重疊有助于減輕重構時的工作量,實現更為高效的軟件維護.為實現這些研究目標,本文深入分析了代碼壞味對軟件演化的影響,其目的在于回答以下4個研究問題.

(1) 壞味密度與壞味活躍度隨著軟件項目的演化如何變化?這些變化具有什么樣的特征?

(2) 當文件包含代碼壞味時,更傾向于發生哪一種變化?文件的變化具體包括文件的新增、修改與刪除,了解這些變化與壞味之間的關系是本文的重要目標.

(3) 具體是哪幾種代碼壞味與文件的變化有著更為顯著的關聯?在第2個問題的基礎上,更進一步地去探究對文件變化產生相對較大影響的壞味類型.

(4) 被不同壞味影響的文件之間是否具有較大的重疊?同一個文件可能包含不同類型的壞味,在維護資源有限的情況下,是否可以僅考慮某幾種類型的壞味加以重點維護.

2.3 實驗對象

本文主要對代碼壞味與軟件演化過程中文件不同類型的變化之間存在的關系進行探究,在實驗對象選取及數據收集的過程中,需要綜合考慮實驗對象的多樣性與數據的充分性兩方面因素.所以,實驗對象的選取遵循以下原則:實驗對象需要具備不同的規模、屬于不同領域,實現了不同的功能,分別由不同的團隊進行研發,這樣保證了研究對象的多樣性;進一步地,這些實驗對象需要具有足夠多的版本、提交數量以及包含壞味文件的數量,因此優先考慮開發時間較長、發布版本較多的項目,以保證數據的充分性.文件發生改變的提交以及需要被檢測的源碼文件均可從 Github上獲取,最終選取了 Che、Egit、Jmeter、Xerces2-j、Jgit、Tomcat、Nifi和Recommenders這8個開源的Java項目進行實證研究,這些實驗對象的主要功能及簡介如下.

(1) Che是一個公共云IDE平臺,可以在公共云、私有云中運行,也可以在任何操作系統上安裝.第1個版本于2016年2月16日發布,到目前為止共有115個版本,最新版本為6.9.0.

(2) Egit是一個用于處理Git存儲庫的Eclipse插件,已經發布了102個版本.第1個版本于2010年3月19日發布,最新版本為v5.0.2-r.

(3) Apache Jmeter是一個性能測試框架,可用于測試具有不同負載和各種配置下的靜態、動態資源和Web動態應用程序.第1個版本于2011年 11月2日發布,到目前為止共有102個版本,最新版本為v4_0.

(4) Xerces2-j是一個高性能的完全兼容的XML解析器,迄今共發布了98個版本.第1個版本于1999年11月9日發布,最新版本是Xerces-J_2_12_0.

(5) Jgit是純Java中Git版本控制系統的一個實現.共發布了107個版本,第1個版本于2010年3月19日發布,最新版本是v5.0.2-r.

(6) Apache Tomcat軟件是Java Servlet、JavaServer Pages、Java Expression Language和Java WebSocket技術的開源實現.共發布了69個版本,第1個版本發布于2009年2月28日,最新版本為9_0_10.

(7) Apache NiFi是一個易于使用、功能強大且可靠的系統,用于處理和分發數據.第1個版本發布于2015年1月23日,迄今共63個版本,最新版本為rel/nifi-1.7.1.

(8) Recommenders通過一系列代碼分析展示來實現代碼推薦功能,共發布了60個版本.第1個版本發布于2011年2月16日,最新版本為v2.5.3.

由于這8個項目都擁有相對較多的發布版本,本文沿用Olbrich等人[4]研究工作中的版本選擇策略,每5個發布版本選擇 1個作為研究版本.此外,需要過濾掉無法使用項目管理工具自動編譯和匯編的初始版本.有關實驗對象的相關信息見表2,其中,|commit|表示第1個與最后一個版本之間所有提交的數量,|V|表示研究中選擇出的版本數量,文件數量范圍表示項目中擁有的所有Java文件的數量范圍.

Table 2 Information of experiment subjects表2 實驗對象信息

2.4 實驗流程

圖1展示了本研究的實驗流程:在確定好研究項目后,首先依據選擇策略挑選出當前實驗版本Vi;接著,根據定義2分別獲取新增文件Ai與被移除文件Ri;隨后,使用工具DIFF來獲取版本之間(Vi與Vi+1之間)的被修改文件Mi;并使用DéCOR區分出每一個實驗版本中的壞味文件Si和非壞味文件Ni;最后,基于上述文件數據,計算并分析壞味文件與新增文件、被修改文件及被移除文件的關系,以了解每一種具體的代碼壞味產生的影響.

Fig.1 Process of experiment圖1 實驗流程

對于每一個研究的版本i,根據公式(3)計算發生 3種不同類型改變的壞味文件在所有壞味文件中的占比,分別計為ASi,MSi,RSi.相應地,根據公式(4)計算發生 3種不同類型改變的非壞味文件在所有非壞味文件中的占比,表示為ANi,MNi,RNi.由此,對于 3種變化類型,可以分別比較壞味文件與非壞味文件發生這些變化的占比,從而分析出哪一種類型的變化與代碼壞味有著顯著的關聯.

在了解了哪一種文件變化類型與代碼壞味更為相關之后,我們進一步探究具體是哪一種或是哪幾種壞味對這種變化類型的影響較為明顯.根據公式(5)計算得到包含某壞味的文件發生特定類型的改變的占比,類似地,可以根據公式(6)獲得不包含此壞味的文件發生各類變化的占比.

通過上述方法,可以得到代碼壞味與 3種文件改變類型之間的相互關聯,以及具體的壞味與這些改變之間的關系.此外,根據公式(7)和公式(8)計算壞味文件之間的重疊率,進一步地探究包含不同壞味的文件之間是否存在較多的重疊,這個探究旨在提供給開發人員更多的信息,以便更為高效地進行代碼重構.

2.5 分析方法

本文使用odds ratio(OR)來評估壞味文件與非壞味文件分別發生3類基本文件操作的傾向.OR值的計算方式如下所示.

其中,p代表了在一組樣例中發生某種事件的比例,而q代表了另一組樣例中同樣事件發生的比例.本研究中,p是指壞味文件發生改變的比例,q則是非壞味文件發生改變的比例.換言之,p值對應了由公式(3)計算得來的AS,MS,RS,而q值則對應公式(4)中的AN,MN,RN.因此,OR＞1表示當文件被壞味影響時有較大的可能性會發生這種類型的文件操作,而OR＜1則代表了相反的含義.

另外,本文有兩處使用了Wilcoxon符號秩檢驗:一是探究在AS,MS,RS數值之間是否存在較為顯著的差異,二是探究被某一種壞味影響的文件發生改變的比例是否高于未被此種壞味影響的文件.Wilcoxon符號秩檢驗是一種非參數檢驗,因此不要求數據是正態分布的.如果檢驗得到的p-value值低于顯著級,則拒絕原假設.

在此基礎上,運用以下公式計算效應值(effect size),用于體現關聯程度的強弱.

其中,Z表示所觀察數據的方差,N表示被觀察數據的總個數.根據Cohen’s效應值的分類,0.1≤r＜0.3表示較小效應,0.3≤r＜0.5表示中等效應,r≥0.5則表示具有較大效應.具體的,在本文中,若效應值低于 0.3,則表示該類型壞味與文件改變并無太大關聯;若效應值高于0.5,則表示該類型壞味與文件改變具有較大的關聯.

3 實驗結果

本節詳細展示了8個項目的實驗結果,并對實驗結果做出相關討論,以回答4個研究問題.

3.1 代碼壞味密度及活躍度的演化

表3展示了研究的8個項目中壞味密度值的范圍和均值.由表可見,代碼壞味密度的值在除了Xerces2-j中較大外,在其他所有項目中都相對較小.

Table 3 Information of code smell density表3 代碼壞味密度信息

圖2為8個實驗項目壞味密度變化的折線圖,其中,橫坐標代表項目的版本,縱坐標代表壞味密度值.

從壞味密度變化的趨勢來看,Che、Egit、Jmeter、Tomcat、Recommenders這 5個項目的壞味密度呈現較為一致的下降趨勢,而另外3個項目的壞味密度則呈現出不同幅度的振蕩.進一步地,壞味密度下降的5個項目也呈現出多種下降特征:Che和 Egit這兩個項目密度值的下降比較平緩,這是因為這兩個項目的總文件數量隨著項目的演化在平穩增長;Jmeter的總文件數量雖是同樣呈現持續上升趨勢,但是由于在第5個版本處含有LPL文件的數量忽然大幅下降,導致密度值在此處驟降;至于Tomcat,在第2個版本處總文件數量出現較大增長且包含AS的文件數量大幅減少導致密度驟降;而Recommenders則是由于在第4版本與第5版本處包含文件總數量發生了相對較大的增長,從而導致密度的陡然下降.另一方面,Xerces2-j、Jgit和Nifi這 3個壞味密度振蕩的項目包含文件的總數量則是隨著版本的演化持續波動,并非持續增長的.

基于壞味密度呈現出不同變化的趨勢,單純從密度值難以得到關于壞味演化的一致結論,因此進一步引入壞味活躍度來反映包含壞味的文件發生變化的占比來探究壞味對文件改變的影響.表4給出代碼壞味活躍度的范圍和均值.

由表4可見,絕大多數項目壞味活躍度的均值低于0.5,即在大多數情況下,只有一半不到的壞味文件將發生文件變更.其中,活躍度均值最高的 Recommenders項目是由于其前期版本中代碼活躍度較高造成的,其后期版本中活躍度明顯下降.結合壞味密度和活躍度發現:在壞味密度呈現下降的 5個項目中,壞味活躍度也呈現出下降的趨勢.

Fig.2 Evolution of code smell density圖2 代碼壞味密度的演化

Table 4 Information of code smell activity表4 代碼壞味活躍度信息

綜上所述,壞味密度的變化呈現出了多種趨勢,而壞味活躍度在大多項目中低于 0.5.由此,我們推測不同的項目處于不同的開發階段,處于非成熟階段的項目將引發諸多基礎功能的改變,從而呈現不穩定的壞味密度與活躍度的演化.即使壞味密度持續下降,往往并非是因為開發人員對壞味存在的關注或是限制,而是因為總的文件數量的變化.因此,我們需要更深入地探究壞味對文件改變的具體影響.

3.2 代碼壞味與不同文件變化類型的相互關聯

圖3展示了8個項目有關代碼壞味與不同文件變化類型之間相互關聯的盒圖.盒圖的橫坐標是根據公式(3)和公式(4)計算得到的結果,分別記為 AS,MS,RS,AN,MN,RN,縱坐標表示壞味文件與非壞味文件中發生 3類不同具體操作的占比.情況相反.至于MS的數值范圍,Che具有最小的數值范圍,壞味文件發生修改的占比均小于0.25,而Jgit具有最高數值范圍,最高占比大于0.9,其次是Xerces2-j.

Fig.3 Proportion of different change types in smelly and non-smelly files圖3 壞味文件與非壞味文件發生不同變化的占比

從占比數值分布的角度來看,不同的研究項目具有不同的特征,但總體而言,我們有如下發現:在 AS,MS,RS幾個數值中,MS具有最高中值,而幾乎所有RS的中值最低;考慮非壞味文件的改變,AN,MN,RN中,MN也高于AN與RN.

為了進一步探究AS,MS,RS的數值分布之間是否具有顯著差異,使用Wilcoxon符號秩檢驗進行評估.設置原假設如下.

(1)H01:AS值與MS值之間沒有顯著性差異;

(2)H02:MS值與RS值之間沒有顯著性差異;

(3)H03:AS值與RS值之間沒有顯著性差異.

表5展示了檢驗得到的p-value值,其中,A-B表示A,B兩組數值對比得到的p-value值,如AS-MS表示H01的p-value值.若p-value值小于0.05,則拒絕原假設.從表5可知,對于H01和H02,所有AS-MS和MS-RS的p-value值均小于0.05,這意味著MS分別與AS,RS之間存在顯著差異,因此拒絕假設H01與H02.對于H03,所有p-value值都大于0.05,不能拒絕假設H03,這表示AS與RS之間不存在顯著差異.

Table 5 p-values for comparison of AS,MS and RS表5 AS,MS和RS的對比p-value值

進一步地,利用 OR值來評估壞味文件與非壞味文件發生改變的傾向.表6匯總了各個項目的 OR值,其中,A,M,R分別表示新增、被修改與被移除文件的 OR值.表中統計了每組OR＞1和OR＜1的數量,分別記為#(OR＞1)和#(OR＜1).

Table 6 Summary of change ORs表6 OR值匯總

由表6可知,對于新增文件的 OR 值,除了 Xerces2-j和 Nifi的所有其他項目,#(OR＜1)高于#(OR＞1).然而Xerces2-j 中#(OR＞1)為 10,對應#(OR＜1)為 8,Nifi 中#(OR＞1)為 6,對應#(OR＜1)為 5,這兩個項目#(OR＞1)與#(OR＜1)十分接近.對于被修改文件的OR值,在所有項目中,#(OR＞1)高于#(OR＜1).對于被移除文件的OR值,除了 Recommenders項目中存在#(OR＞1)等于#(OR＜1)外,在其他所有項目中有:#(OR＜1)高于#(OR＞1).

OR值體現了代碼壞味與文件的具體操作類型之間的關聯,其中,被修改文件的OR值大于1,則代表了包含壞味的文件更傾向于被修改.根據上述實驗結果與分析,我們可以得出以下結論:壞味文件更傾向于被修改,而代碼壞味與文件的新增或是被移除沒有很大的關聯.

上述實證研究結果證實了Khomh等人[26]關于壞味文件更具有改變傾向、錯誤傾向的結論,進一步得出了壞味文件更傾向于被修改的結論,并從更大規模的項目實證再次證實了我們前期的研究成果[31].壞味文件更傾向于被修改的現象提醒開發人員,應在開發過程中重視代碼壞味的檢測和及時消除,以減少代碼壞味對后續的開發與維護的不良影響.

3.3 特定類型的代碼壞味與文件變化的相互關聯

基于第3.2節中代碼壞味與文件修改更為相關的結果,本節進一步探究具體是哪一種或是哪幾種壞味對文件修改產生較大的影響.因此,分別計算包含某一種壞味的文件與不包含這種壞味的文件發生修改的占比.

在對壞味進行檢測的過程中發現,并非所有的13種壞味都存在于各個項目中.但能夠檢測到的壞味大多隨著版本的演化一直存在于項目中,即這些壞味存在于每個項目的所有版本中.為了保證研究的可靠性,本文僅對存在于該項目所有版本中的代碼壞味進行研究.這是由于要探究特定類型的壞味與文件修改之間的相互關聯,若是其中某一版本中不存在受某種壞味影響的文件,不僅實驗結果會產生誤差,同時也因為不存在該壞味而缺失了研究的意義.

圖4展示了被特定類型壞味影響的文件與未被該壞味影響的文件發生修改的占比.圖4中使用了壞味名稱縮寫以便更加清晰地表示,如Bb表示Modified(Blob),non-Bb表示Modified(non-Blob).

Fig.4 Proportion of modified files in certain smell files and the files that not contain the smell圖4 包含特定類型壞味的文件與不包含該壞味的文件被修改的占比

基于圖4的信息,表7匯總了特定類型壞味與文件修改的關聯信息,其中,“√”表示該種壞味在對應項目中表現出與文件修改有較大關聯,“×”則表示關聯度較小,“-”表示未檢測到此種壞味.

Table 7 Correlations between code smell and file modification表7 壞味與文件修改的關聯

從圖4、表7中可以看出,所有項目中都包含被CC與LPL影響的文件,并且這些文件都有較大的被修改傾向;相反的,YC與文件修改不存在顯著性關聯.至于AS,Bb和CP這幾種壞味,它們在不同的項目中對文件修改產生的影響則不盡相同:在 Che、Egit、Xerces2-j、Jgit、Tomcat、Recommenders中,包含 Bb的文件有較大可能性被修改,而在Nifi中,Bb并不呈現這樣的特征;AS在Che中對文件修改的影響不大,而在Egit、Xerces2-j、Tomcat、Nifi、Recommenders中對文件的修改影響較大;Che、Jgit、Tomcat中,被 CP影響的文件發生修改的可能性不大,而另一些項目中被影響的文件有較大的可能性被修改.

進一步地,我們使用 Wilcoxon符號秩檢驗來探究包含特定類型壞味的文件是否與文件修改有著較強的相互關聯.對于每一種特定類型的代碼壞味,設置原假設H04:包含該種壞味的文件發生修改的占比與不包含該壞味的文件發生修改的占比不存在顯著性差異.若檢驗得到的p-value值小于0.05,將否定原假設,并進一步計算效應值.表8展示了具體的p-value及效應值,當p-value值大于0.05時,對應數值加“*”表示.

Table 8 p-values and effect size表8 p-value值與效應值

如表8所示,有5種代碼壞味需要引起我們的關注.具體來說,CC與LPL這2種壞味在所有8個項目中均有p-value值小于0.05,效應值大于0.5,充分說明這兩種壞味會對文件的修改產生較大的影響.AS,Bb,CP則并非存在于所有的項目中,且對不同項目中文件修改的影響也不盡相同.例如,AS在 Tomcat和 Recommenders中的p-value值大于0.05,表示該壞味在這兩個項目中與文件修改的關聯度不大;而在另外的項目中則顯示出較強的關聯.類似地,Bb在Xerces2-j和Nifi這2個項目中,CP在Recommenders中的p-value值均大于0.05.

通過分析上述5種代碼壞味與文件修改之間的關聯,我們發現,CC,LPL與文件的修改之間存在較大的關聯.另外,我們仍需多加關注 Bb,該壞味存在于除了 Jmeter以外的所有項目中,且在多個項目中還具有較大的效應值,對文件修改的影響也相對較大.AS與CP若是存在于項目中,也需要引起一定的關注.

3.4 壞味文件的重疊

基于第 3.3節中壞味與文件修改之間關聯度的分析,本節計算受到 5種特定類型代碼壞味(AS,Bb,CP,CC,LPL)影響的共同文件在各自壞味文件中的占比.為了便于觀察與分析,表9僅列舉各個項目中根據公式(7)和公式(8)計算得到的重疊率均值大于0.1的情況.

Table 9 Overlaps between specific smelly files表9 不同壞味文件的重疊率

從表9可知,受CC與LPL影響的文件在所有項目中的均值都高于0.1,其中,同時包含這兩種壞味的文件在CC中的占比均值最低為0.165,最高為0.693;在LPL中的占比均值最低為0.135,最高為0.296.這表明CC與LPL這兩種壞味存在著共生現象,往往同時存在于同一項目中,且這兩種壞味文件有一定程度的重疊.這些現象與這兩種壞味的定義相一致,這兩種壞味分別代表了具有復雜圈復雜度、較多代碼行數和長參數列表的代碼片段.類似地,AS與CP在6個項目中存在著共生現象.值得注意的是,這兩種壞味文件的重疊程度很大,在AS中的占比最高為0.924,在CP中的占比最高為0.956.這表明,項目中很大比例的文件同時受到AS與CP這兩種壞味的影響.

進一步深入分析壞味文件的數量可以發現:雖然CC與LPL的重疊率整體上并不是很高,但在所有項目中,被 CC與 LPL同時影響的文件數量較多,例如,Jgit中同時包含這兩種壞味的文件數量在各個版本中的均值為13,而其余壞味文件的重疊數量均值都低于3.對于AS與CP這兩種壞味,除了Che中同時被這兩種壞味影響的文件數量大于 65以外,其他項目中同時被這兩種壞味影響的文件數量較少,最高僅為 19.在少量重疊文件而高重疊率的情況下,同時對AS與CP這兩種壞味進行代碼重構,消除壞味的影響將事半功倍.

此外,被CC與其他壞味共同影響的文件往往占據其他壞味文件較大的比例,例如AS_and_CC_in_AS在6個項目中重疊率高于0.1,而AS_and_CC_in_CC僅在2個項目中重疊率高于0.1.這說明CC壞味文件數量往往大于AS壞味文件數量.除CC之外,LPL也具有類似的特征.因此,壞味文件數量較高的CC與LPL應該在重構時優先考慮,以提高重構效率.

通過上述觀察可知,在代碼重構過程中,應綜合考慮存在共生現象的CC與LPL、AS與CP壞味文件,力求共同消除.特別地,應該提高CC和LPL這兩種壞味文件的維護優先級.此外,AS,Bb,CP這幾種壞味也不可忽視.

3.5 討 論

存在于各個項目中不同的壞味密度與活躍度的特征,促使我們探究壞味與文件改變之間的相互關聯.正如代碼壞味的相關定義,壞味是指會影響代碼結構與可理解性的不友好片段,我們的探究表明,壞味的存在會導致文件內容發生修改,而不會影響到整個項目的基本框架.我們推測,開發者們在開發過程中更注重實現功能需求而忽視壞味的存在,往往會給后續的開發與維護帶來一定的困難.從另一個角度來看,如果壞味問題得到有效的解決,那么將極大地減少由壞味引起的文件修改的成本.

根據文件修改與具體壞味之間的關聯與包含不同壞味文件之間的重疊率,我們的研究提供給開發者有關包含壞味文件維護的有效建議,如提升包含ComplexClass和LongParameterList這兩種壞味文件的維護優先級、維護時可同時考慮消除AntiSingleton與ClassDataShouldBePrivate這兩種壞味的影響等,以實現更為高效的代碼維護.

和多數的實證研究一樣,本文的工作也存在以下內部與外部因素對可靠性的影響.

(1) 內部影響:其中一個主要威脅是實驗環境的準確性.首先,我們使用DéCOR檢測代碼壞味,代碼壞味的定義本身具有一定的主觀性,這可能是一個對本研究可靠性的潛在威脅.但是作為一個被廣泛應用的代碼壞味自動檢測工具,DéCOR檢測壞味的召回率為 100%,平均準確率為 60%,因此我們認為,由DéCOR檢測的壞味是可以用于該實證研究的.另外,我們對實驗環境進行了仔細的檢查與測試,以保證實驗的有效性.

(2) 外部影響:我們僅對8個Java項目進行了實證研究.這些項目具有相對較大的規模并且應用于多個領域,并且我們共計探究了 104個項目版本,從這些版本中得到的數據足夠支持我們的研究.我們相信,這樣的實驗規模足以保證該研究的有效性.然而,對更大的系統進行進一步驗證,可以幫助推廣我們的發現.此外,我們的實驗是在文件級別進行的,將來我們可以將實驗設置到類級別,以探索源代碼和壞味之間更精確的相關性.

4 總 結

本文系統開展了關于代碼壞味對軟件演化影響的實證研究,分析了代碼壞味與源文件變更之間的相關性.文件的變更細化為新增文件、修改文件和移除文件這3類具體操作,目的是探究這些不同的操作類型是否均與壞味相關.本文針對8個Java項目的104個版本,運用DéCOR工具檢測13種不同類型的壞味,實驗結果表明.

(1) 代碼壞味的密度和活躍度在不同的項目中呈現不同的特征,大部分項目的壞味密度隨著軟件的不斷演化呈現下降趨勢,且壞味活躍度通常不高.

(2) 與不含壞味的文件相比,含有壞味的文件更容易被修改.此外,代碼壞味與文件的添加和移除沒有明顯的關聯.

(3) ComplexClass和 LongParameterList這兩類壞味與文件的修改更為相關;此外,如果項目中存在AntiSingleton、Blob和ClassDataShouldBePrivate這些壞味,仍然需要重視它們產生的影響.

(4) 軟件維護的過程中可考慮AntiSingleton和ClassDataShouldBePrivate這兩種壞味的特征同時進行重構;包含ComplexClass和LongParameterList這兩種壞味的文件有較大的可能性包含其他壞味,且被這兩種壞味影響的文件重疊率較高、重疊文件數量較多,應提高這兩種壞味的重構優先級.

本文采用大規模的實證研究,深入分析了代碼壞味對軟件演化的影響,并為開發人員在軟件維護過程中如何有效地重構代碼給出了相關建議:開發人員應該更多地關注包含代碼壞味的文件,尤其是包含 ComplexClass或LongParameterList的文件,避免引入這些壞味,將極大地降低文件被修改的可能性,從而降低整個軟件生命周期中維護成本.在未來的工作中,將分析更多的項目,并在更為細化的級別上進行深入的實證研究.此外,擬引入人的因素,如熟悉度、中心性和所有權等,以討論代碼壞味產生的影響.