面向開源軟件的自承認代碼重構現象研究

張 迪,李增揚,李 兵,梁 鵬

(武漢大學 計算機學院,武漢 430072)

1 引 言

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

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

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

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

2 相關研究

在這一節中,我們將從三個方面討論與自承認重構領域相關的研究工作.

2.1 代碼異味與重構

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

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

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

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

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

2.3 自承認現象的研究

自承認現象的研究,在技術債務研究領域比較流行.Potdar和Shihab對自承認技術債務(Self-admitted technical debt)進行了探索性研究,發現在2.4%的文件中存在自承認技術債務,而26.3%～63.5%的自承認技術債務在引入后會被清除[11].

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

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

3 研究設計

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

3.1 目標與研究問題

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

RQ1:SAR改善了源代碼的結構質量嗎?

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

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

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

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

代碼異味的數量可以在一定程度上反映軟件系統的結構質量.所以,SAR中的代碼異味是否少于非SAR是一個值得研究的問題.

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

代碼異味檢測工具提供了代碼異味的嚴重級別,其代表著代碼異味的嚴重程度和修復的優先等級.在SAR中,代碼異味嚴重程度的分布可以用來評估代碼的總體質量狀態.

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

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

RQ3:是否有開發者傾向于自承認重構?

不同的開發者有不同的代碼風格和代碼理解能力.自承認重構信息是基于自然語言基礎上的,因此SAR是否與開發者的經驗、寫作風格或者提交次數有關系,是研究SAR現象的關鍵.

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

SAR分布是否平衡反映著軟件項目開發周期中的自承認重構狀態,了解SAR分布對我們了解整體軟件生命周期狀態將有所幫助和啟發.

3.2 案例選取

本研究主要探索SAR現象,因此以SAR作為分析單元.我們將采用以下標準對案例進行選取:

·所選項目應具有兩年以上的歷史.

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

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

·所選項目的開發開發者數目需超過10個.

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

·項目完整的提交數據列表可以由TortoiseGit客戶端導出.

3.3 數據收集過程

3.3.1 需收集的數據

為了回答第3.1節中定義的RQs,表1中列出了我們需要收集的數據項,也列出了每個數據項對應的目標RQ(s).

3.3.2 數據收集方法

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

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

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

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

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

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

表1 需收集的數據項

3.3.3 非SAR版本收集

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

圖1 SAR收集過程

3.3.4 代碼異味收集

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

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

圖2 Code smell的收集過程

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

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

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

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

3.3.5 數據分析方法

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

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

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

為了回答RQ3,將會統計所有參與開發項目的開發者作者信息,以及有關SAR作者信息(包括用戶名,郵件,提交次數,SAR提交次數).計算SAR開發者所占的數量SAR作者在軟件開發過程中自承認重構對應的比例.

對于RQ4,利用已收集的SAR信息,進行位置標注,用Matlab程序對SAR分布進了圖形描述.以確認和總觀SAR在項目周期中的分布特點.表2概括總結了分析的方法.

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

表2 數據分析方法

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

表3 PMD規則

4 研究結果

4.1 所選項目

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

表4 項目統計信息

4.2 結果

4.2.1 代碼質量的影響(RQ1)

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

表5 DNCS信息

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

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

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

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

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

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

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

RQ1.2:在本文的案例研究中,有121個SAR版本與121個隨機的非SAR版本.如表7所示,在非SAR版本中,代碼異味增加(DNCS>0),保持不變(DNCS=0),減少(DNCS<0)的情況分別為76、29和16.而在SAR版本中,代碼異味的數量增加(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種代碼異味.其中定義了每個代碼異味的嚴重級別(使用1-5來表示),分別為:Error High、Error、Warning High、Warning和Information.表7展示了PMD標識的代碼異味的默認的嚴重級別的分布.#(PMD code smell type)表示PMD中定義的相應嚴重級別的代碼異味數量.DNCS定義為SAR中代碼異味數量的增量.#(PMD code smell)表示PMD在項目中實際檢測到的代碼異味嚴重級別的數量.#(Detected code smell type)是實際檢測到的代碼異味類型的數量.類型比例表示PMD可以檢測到的代碼異味類型占所有代碼異味類型的比例.

表7 代碼異味的變化量

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

表8 代碼異味嚴重級別分布

4.2.2 被修改的源文件數量與引進代碼異味數量的關系(RQ2)

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

表9 NMF 分布

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

表10 相關性結果

4.2.3 有關SAR開發者(RQ3)

并不是所有開發者在軟件開發過程中都具有自承認重構行為.在分析了Fastjson的提交信息之后,我們發現特定的開發者具有SAR行為傾向.表11顯示了在項目中執行SAR的開發者信息.FSC指參與項目的總開發人員數量、SAR開發者代表自承認重構的提交總人數.

表11 開發者信息

圖3展示了每個SAR開發者所產生的SAR的數量.其中有大量使用了不同網絡身份的開發者.我們通過身份語義、郵箱等關鍵信息分析并合并了不同的網絡身份,最后產生了3個SAR開發者的合并集合.結果顯示,提交人3在Fastjson項目中執行了大部分(108/121)的自承認重構.

圖3 開發者SAR數量

此外,我們計算了SAR開發者自承認件重構次數占其自身提交總次數的比例,結果如表12所示,每個SAR開發者的僅有不超過20%的SAR行為.

表12 SAR開發者的SAR比例

4.2.4 自承認重構分布(RQ4)

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

圖4 Fastjson的SAR分布

5 討 論

5.1 研究結果分析

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

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

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

RQ3:如表12所示,我們可以看到只有6.25%的開發者在提交記錄中自承認軟件重構.在SAR開發者的提交記錄中,SAR的提交次數所占的比例也是較小的.

RQ4:自承認重構行為大部分發生在了Fastjson的開發初期與中期,這表示在項目開發生命周期中的不成熟階段,即頻繁進行質量改進活動.

5.2 啟發性信息

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

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

SAR表明了開發人員對代碼質量改進的認識,因為開發人員明確地宣稱了重構,在某種程度上表明了他們進行代碼結構質量改進的意愿.SAR的作用除了標記重構信息,記錄版本更新以外,在多人協同開發過程中,也為接下來他人接替代碼項目起到了提示作用.

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

5.3 有效性威脅

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

6 總 結

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

正如我們看到的,自承認重構總體上提高了代碼質量.在本文有關SAR的案例研究中,有很多可以切入并深入研究細節,未來我們對SAR的研究將側重于以下幾個方面:

·SAR與自承認技術債務的關系.自承認技術債務往往是開發者特意為之,需要有計劃地通過重構來進行償還.自承認技術債務與SAR的關系,自承認技術債務和SAR是如何來共同影響軟件代碼質量和軟件的可維護性的,都值得下一步深入研究.

·更多案例的SAR分析.SAR在不同的項目上,表現可能會有所不同.我們將對不同應用領域中的更多的軟件項目上進行本文案例分析的重復性研究,探索是否得到關于SAR的共性結論.

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

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

·細化SAR的劃分.在本文中,我們利用關鍵字搜索的方式簡單地對SAR進行了挑選,然而事實上,自承認重構的表現復雜,比如關鍵字Move Method等,原則上也應該劃分為SAR.我們可以利用數據挖掘的方式深入進行SAR的識別工作.