開源社區評審過程度量體系及其實證研究*

蔣 競,吳秋迪,張 莉

(北京航空航天大學 計算機學院,北京 100191)

開源軟件特有的開發模式激活大眾創新潛力、提高創新效率.開源社區里的開發人員可以下載源碼,并在本地代碼庫進行修改,協同進行軟件開發.但是,不同開發人員提交的代碼水平參差不齊,代碼風格也不盡相同,需要代碼評審檢查提交代碼質量[1].決策者是代碼評審的關鍵人物,審核開發人員提交的代碼,決定是否將其添加到源代碼庫.此外,開發人員也可以對代碼改動和評審過程發表評論.代碼評審要綜合考慮代碼質量、文檔質量、測試結果、需求測試結果等因素.代碼只有通過評審后,才能集成到源代碼庫中;未通過評審的代碼會被開源項目拒絕,不會影響到開源軟件的質量.代碼評審能夠提前發現項目存在的缺陷,減少了返工時間以及測試時間,保證開源軟件質量.因此,需要建立評審過程度量體系,了解代碼評審情況,發現容易出現軟件缺陷的高風險軟件模塊,促進提高開源軟件項目質量.

為了解軟件開發情況,研究人員提出了過程度量方法.Bird 等人[2]提出了一種基于開發過程度量體系,分析不同人員在同一模塊的代碼貢獻量,通過過程度量體系評估這些人員的開源軟件開發過程,來分析開源開發過程與軟件缺陷的關系.然而,他們的工作只針對了開源軟件開發過程,并沒有考慮評審過程.Thongtanunam 等人結合開發代碼貢獻量和評審評論貢獻量,建立了一種結合評論的評審過程度量方法[3].然而,他們只考慮評審過程中的評論活動,忽略決策活動.在代碼評審里,決策者才是起關鍵作用的角色,直接決定了代碼改動是否能夠加入源代碼庫里.

決策者是代碼評審過程中的關鍵人物,以往的研究沒有考慮決策者的活動.本文引入決策者因素,提出了一個開源社區評審過程度量體系,從多個指標的角度分析評審過程與軟件缺陷數量的關系.首先建立度量體系的度量指標,分別是評審活動指標和人員分布指標.評審活動指標包含評審次數、評審信息長度、代碼改動行數以及評審時間.人員分布指標里考慮改動者、評論者和決策者的比例和數量.然后收集3 個熱門開源項目數據,分析評審過程度量指標與軟件缺陷數量的關系.實證研究發現:一些度量指標和軟件缺陷數量至少中等正相關,例如決策者數量,少改動、少評論、少決策者的比例等.這些指標的數值越大,軟件缺陷數量越多.同時,與不考慮決策者的度量體系進行對比分析,發現含有決策者的度量體系和軟件缺陷的相關性更高.實證研究結果驗證了本文提出評審過程度量體系的有效性,說明增加決策者相關指標的必要性.

本文的主要貢獻包括:

(1) 首次引入決策者因素,考慮決策者在評審過程的重要作用,提出了一個開源社區評審過程度量體系;

(2) 實證研究發現:和現有的度量體系相比,發現含有決策者的度量體系和軟件缺陷的相關性更高.

本文第1 節介紹研究背景.第2 節介紹相關研究工作.第3 節介紹評審過程的度量指標.第4 節進行實證研究,爬取真實數據,計算得出評審過程的各種指標,最后分析評審過程度量指標與軟件缺陷的關系.第5 節討論有效性和論文啟示.第6 節總結全文.

1 背景介紹

Github 是一個著名的開源軟件平臺[4-8].Github 可以看做一個開源代碼庫,同時也能作為庫的版本控制系統,因此有900 多萬的用戶選擇在Github 上面進行軟件開發.現如今,Github 已經成為了開發人員進行開源軟件開發的首選.我們的所有研究也都是基于Github 的.

如圖1 所示,以GitHub 為例的開源軟件平臺代碼評審[9-12]主要包括以下步驟.

(1) 開發人員可以拷貝開源項目的代碼,建立副本,并在副本上進行代碼修改.但是如果他們想向源代碼庫提交自己的代碼,就需要發出一條貢獻請求,其中包括要修改的代碼.貢獻請求就是開發人員提交的一組代碼和文本描述.開發人員如果想將修改的代碼整合到開源項目時,可以向開源項目提交貢獻請求.這些提交了貢獻請求的開發人員被稱為改動者;

(2) 這種貢獻請求是公開的,任何人都可以對貢獻請求發表評論.發表評論的人員被稱作評論者;

(3) 決策者是可以評審代碼、修改項目代碼庫的核心開發人員.決策者對貢獻請求進行檢查,并且可以參考評論里的意見,對貢獻請求的質量進行評估.如果通過,則這段代碼可以提交到源代碼.在評審結束后,決策者關閉貢獻請求.

Fig.1 GitHub review process圖1 GitHub 評審流程

從Github 的評審流程可以看出:代碼評審能夠對提交的代碼進行評估和改進,發現提交代碼的缺陷.因此,代碼評審對軟件質量有著直接的影響.研究代碼評審過程,能夠更好地管理開源軟件質量,減少軟件缺陷.以往的研究[2,3]都沒有考慮評審過程中決策者的作用,然而在評審過程中,決策者是代碼評審的關鍵人物,只有經過決策者審核通過的代碼才能加入到源代碼庫里.因此,本文的開源社區評審過程度量體系會考慮決策者因素.

2 相關研究

為了解軟件開發情況,研究人員提出了過程度量方法.首先,Bird 等人[2]提出了一種基于軟件開發的過程度量體系,通過計算開發人員在文件內編寫的代碼更改的比例,計算文件內開發人員的代碼貢獻量,來度量開發人員的軟件開發過程.然后,根據過程度量體系的指標分析開發過程與軟件缺陷的關系.然而,他們的工作只針對了開發人員在軟件開發過程中的表現,并沒有考慮評審過程對于軟件缺陷的影響.其次,Thongtanunam 等人[3]研究了QT 和OpenStack 平臺里改動者和評論者在評審過程中的貢獻與分布.他們發現:許多評論者在傳統指標里被定義為次要貢獻者,但是在考慮了評論因素的指標里卻被定義為主要貢獻者.在無缺陷的文件里,有著相當大比例的開發者在傳統指標里的貢獻量比較低,而在引入評論因素的指標里貢獻量比較高.他們的研究表明:傳統的貢獻量指標會忽略評論貢獻,然而無缺陷的軟件卻擁有更多的高評論貢獻量開發人員,說明傳統的貢獻量指標不足夠.但是Thongtanunam 等人只計算了評論者和改動者對于軟件缺陷的影響,缺乏考慮評審過程的重要角色決策者.在開源軟件開發過程中,決策者發揮重要作用,決定代碼改動是否能否集成到開源項目.現有文獻[2,3]缺乏考慮決策者,難以充分度量評審過程.本文引入決策者因素,分析度量指標與軟件缺陷數量的關系.

貢獻請求的代碼評審近年來得到了廣泛的關注.首先,一些學者研究貢獻請求的決策者或者評論者推薦方法.莫納什大學夏鑫等人提出了一種結合文件路徑和文本描述的決策者推薦方法[13].Kim 等人提出了基于主題模型的決策者推薦方法.Thongtanunam 等人提出了基于文件路徑的決策者推薦方法[14].國防科技大學的余躍、王懷民等人分析了開源軟件平臺的歷史數據,建立了評論關系網絡,對貢獻請求推薦合適的評論者[15-17].中國科學院的盧松等人提出了基于時間和影響力因子的評論者推薦方法[18].其次,一些研究人員對大眾貢獻評審結果展開研究.Weigerber 等人發現,修改量小的代碼更容易通過評審[19].Bosu 等人發現,項目核心人員提交的代碼質量更高,更容易通過評審[20].Gousios 等人提出一種基于隨機森林的貢獻結果預測方法[21].Tsay 等人結合社交因素和技術因素預測評審結果[22].雖然這些論文研究問題和本文不同,但是都關注代碼評審的貢獻請求,研究思路和指標值得本文借鑒.

3 評審過程度量體系

代碼評審是保證開源軟件質量的重要環節.本文研究評審過程度量體系,對開源項目的評審過程進行評估.參考以往論文[3],本文提出兩個方面的指標:首先是評審活動指標,用來評估評審活動的情況,包括評審時間、評審次數、評審信息長度、代碼改動行數;然后是人員分布指標,反映改動者、評論者和決策者的分布情況.

項目里不同的文件代碼規模懸殊,根據文件來計算度量指標差異會很大.根據文獻[3]使用模塊來確定統計對象,對同屬于一個子文件夾下的文件計算指標.對于一個模塊M,FSetM是模塊M里的文件集合,PSetM是改動過模塊M的貢獻請求集合,DSetM是改動、評論或者決策過模塊M的用戶集合,其中,CSetM是改動模塊M的改動者集合,RSetM是評論模塊M的評論者集合,ISetM是評審模塊M的決策者集合.對于一個貢獻請求Pi(Pi∈PSetM),定義其評論條數為I(Pi),評審時間為T(Pi).對于一個文件Fi(Fi∈FSetM),a(Fi),d(Fi),m(Fi)分別為文件Fi里增加、刪除、修改的代碼行數.對于一個用戶Di(Di∈DSetM),CH(Di,M)為用戶Di對模塊M做出的改動的行數,RE(Di,M)是用戶Di在模塊M里的評論總數,PR(Di,M)為Di在模塊M里決策了的貢獻請求數目.

3.1 評審活動

定義1(評審次數).評審次數是一個模塊所經歷的所有評審次數.對于一條被整合進入源代碼庫的貢獻請求,它的代碼改動必然涉及到某些模塊.每有一條貢獻請求改動了模塊M,就稱模塊M經歷了一次評審.PSetM是改動過模塊M的貢獻請求集合,card(PSetM)是PSetM集合里的貢獻請求數目,就是模塊M的評審次數.評審次數N為N=card(PSetM) (1)

定義2(評審信息長度).評審信息是評審過程中的評論條數.在評審一個貢獻請求的時候,人們可以對其提出自己的批注和意見.評審信息反映改動的代碼是否經過了大量討論.對于一個模塊的評審信息長度,定義為這個模塊中每條貢獻請求的評論條數之和.M是選定的一個模塊.則評審信息長度L為

定義3(代碼改動行數).代碼修改最重要的特征之一,就是代碼改動的行數,包括代碼的增添、刪減和修改行數.這些屬性是一個代碼改動核心的特征,通過代碼的增添、刪減和改動行數,可以清楚地知道軟件在一段時間內究竟有多少改動.一個模塊的代碼改動行數CH(M),就是這個模塊中所有文件的增添、刪除和修改的代碼行數:

定義4(評審時間).一個貢獻請求從創建開始,一直到評審結束持續的時間.評審時間以模塊為單位,計算一個模塊里貢獻請求的評審時間之和.M是選定的一個模塊.則評審時間T定義為

3.2 人員分布

定義5(改動者數量).假如一個文件里面,提交代碼修改的人數越多,那么提交的代碼風格可能差異越大.找出模塊的貢獻請求集合中所有的改動者集合,計算集合里的改動者數目.改動者數量C為

定義6(評論者數量).在評審過程中,評論者對評審結果有直接影響.評論者可以對代碼修改提出自己的意見,比如指出代碼修改里面的不足,而這些評論可以作為后面決策工作的參考.找出模塊的貢獻請求集合中所有的評論者集合,計算集合里的評論者數目.評論者數量R為

定義7(決策者數量).決策者是能夠直接決定代碼修改是否能整合進源代碼庫的人員,決策者是直接決定評審結果的人員.根據模塊的貢獻請求集合計算所有的決策者數目.決策者數量I為

在Patanamon 的論文[3]里,他們提出了貢獻量這一說法.貢獻量就是評估開發人員給項目做的貢獻多少,比如作者的貢獻量就是修改代碼的多少、評論者貢獻量就是評論數目的多少.代碼貢獻量為大型軟件系統中的模塊建立了一系列的責任鏈.雖然之前的工作揭示了代碼貢獻量、評論貢獻量與軟件缺陷之間的聯系,但這些啟發式僅依賴于代碼更改的作者和評論者.除了編寫代碼更改和評論之外,還有決策者對模塊做出重要貢獻.決策者可以決定代碼修改是否能被整合進源代碼庫中,作為評審活動中重要的一環,將決策者也加入到貢獻量計算中.提出了3 種貢獻量的計算方式.

? 代碼貢獻量

作者是最基本的一種開發人員,給項目添加代碼改動的開發人員就是作者.作者提交的代碼改動是評審的基礎和對象.而代碼貢獻量就是評估作者對項目的貢獻.

定義8(代碼貢獻量).M是選定的一個模塊,那么用戶Di在模塊M中所占的代碼貢獻量TCO(Di,M)為

? 評論貢獻量

評論者雖然不能直接影響評審結果,但是評論者的評論可以作為決策者提供參考.評論數目反映一條代碼修改是否經歷了大量的討論.

定義9(評論貢獻量).M是選定的一個模塊,那么用戶Di 在模塊M中所占的評論貢獻量RSO(Di,M)為

? 決策貢獻量

決策者是可以把代碼修改整合進入源代碼庫的內部人員.過去的論文都沒有討論過決策者的作用,然而決策者作為直接評審的人員,肯定是不容忽視的.

定義10(決策貢獻量).M是我們研究的一個模塊,那么用戶Di在模塊M中所占的決策貢獻量ISO(Di,M)為

各種類型的人員并不是完全獨立的,評審過程中的開發人員可能同時扮演幾種角色.為了準確地分析評審過程里的人員組成,需要根據不同的貢獻量將人員進行劃分,并將模塊中不同類型人員的比例作為度量指標.文獻[2,3]以0.05 為閾值,按照貢獻量劃分開發人員的角色.類似的,本文也按貢獻量來劃分主要、次要貢獻者.在一個模塊中,如果一個人某個方面的貢獻量比例大于等于0.05,則稱他是這個方面的主要貢獻者.根據人員在改動、評論或者決策的貢獻量比例來給他們劃分角色.例如一個人TCO≥0.05,RSO≤0.05,ISO≥0.05,那么他是主要代碼改動貢獻者、次要評論貢獻者、主要決策貢獻者.由此可以將用戶分為8 類,并計算這8 類用戶在模塊里的比例作為度量指標.

? 多改動、多評論、多決策者的比例:TCO≥0.05,RSO≥0.05,ISO≥0.05 的人員比例;

? 多改動、少評論、多決策者的比例:TCO≤0.05,RSO≥0.05,ISO≥0.05 的人員比例;

? 少改動、多評論、多決策者的比例:TCO≥0.05,RSO≤0.05,ISO≥0.05 的人員比例;

? 少改動、少評論、多決策者的比例:TCO≤0.05,RSO≤0.05,ISO≥0.05 的人員比例;

? 多改動、多評論、少決策者的比例:TCO≥0.05,RSO≥0.05,ISO≤0.05 的人員比例;

? 多改動、少評論、少決策者的比例:TCO≤0.05,RSO≥0.05,ISO≤0.05 的人員比例;

? 少改動、多評論、少決策者的比例:TCO≥0.05,RSO≤0.05,ISO≤0.05 的人員比例;

? 少改動、少評論、少決策者的比例:TCO≤0.05,RSO≤0.05,ISO≤0.05 的人員比例.

表1 中給出了評審過程度量指標的定義和描述,這些度量指標從評審活動和人員分布兩方面詮釋了軟件評審過程中的多維屬性.

Table 1 Review process metrics表1 評審過程度量指標

4 實證研究

為了驗證度量體系的有效性和實用性,同時為了進一步研究評審過程指標與軟件缺陷的相關性,本文采用Github 的真實數據來進行實證研究.如圖2 所示,參考Patanamon 的論文[23],本文把數據分成3 部分:上一個時間段、當前時間段、下一個時間段.每個時間段都是6 個月.上一個時間段的數據用來計算之前的軟件缺陷;當前時間段的數據用來計算當前的評審過程指標;下一個時間段的數據用來計算評審后的軟件缺陷.然后,基于度量評估體系對原始數據進行加工處理,計算得出各種指標,最后使用相關性分析方法研究評審過程度量指標與軟件缺陷的關系.相關系數的絕對值越大,說明度量指標和軟件缺陷數量越相關,度量指標越有效.

具體來講,本文從兩個方面研究度量指標和軟件缺陷的相關性.首先,計算當前時間段的代碼評審度量指標和下一個時間段軟件缺陷數量的關系,來研究當前的評審過程是影響下一個時間段的軟件缺陷.比如:當前時間的評審時間更長,下一個時間段的軟件缺陷是否更少.然后,計算上一個時間段的軟件缺陷數量與當前時間段的評審過程度量指標的相關性,研究之前存在的軟件缺陷是否會對當前的代碼評審過程造成影響.比如:上一個時間段軟件缺陷數量多的模塊,是否會在當前代碼評審的時間更長.

4.1 研究過程

4.1.1 項目選擇

根據Github 上項目的關注人數和貢獻請求數,本文選取3 個熱門項目:xbmc,roslyn,elasticsearch.xbmc (https://github.com/xbmc/xbmc)是一款優秀的免費開源媒體中心軟件,可以播放幾乎所有的音頻和視頻格式.roslyn(https://github.com/dotnet/roslyn)是微軟開發的一個開源的.NET 編譯器,支持 C#和 Visual Basic.elasticsearch(https://github.com/elastic/elasticsearch)是一個基于Lucene 的搜索服務器,提供了一個分布式的搜索引擎.這些熱門項目關注人數多,提交的貢獻請求也多,分析結果才具有統計意義.

Fig.2 Data partition圖2 數據劃分

4.1.2 數據收集

采用的是Github 自帶的API 進行數據獲取.爬取的內容包貢獻請求信息,這里指貢獻請求編號、代碼提交編號、創建時間、提交時間以及貢獻請求下面的評論信息等.這些數據包含了一個貢獻請求的所有信息,也可以將貢獻請求與代碼提交聯系起來.接下來爬取代碼提交信息,包括改動行數、文件名、改動者、決策者、評論信息、對應的貢獻請求編號.這些數據文件包含了代碼提交的所有信息,可以知道每條代碼提交對應的模塊.最后收集各種評論信息,包括了評論對應的貢獻請求編號、評論者、評論條數.表2 統計了3 個項目的數據.本文將數據集上傳,以供研究者參考(https://github.com/wqdbuaa/Dataset).

Table 2 Project data statistics表2 項目數據統計

4.1.3 軟件缺陷

軟件缺陷又被稱作BUG,即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤,或者隱藏的功能缺陷.缺陷的存在,會導致軟件產品在某種程度上不能滿足用戶的需要.一個軟件的質量是跟它的軟件缺陷相掛鉤的.軟件缺陷多,說明這個軟件質量差.本文采用的是Ray 在其論文[24]中使用的一種啟發式的方法來對缺陷進行識別.找出一個貢獻請求的提交信息,利用自然語言處理把提交信息進行分詞,最后得到的詞匯集合與錯誤詞集進行匹配[25].如果提交信息里面包含錯誤關鍵詞,那么可以認為這條貢獻請求有缺陷,該條貢獻請求所涉及的文件也視為有缺陷[24].Ray 在文獻[24]中使用的錯誤關鍵字為error,bug,fix,issue,mistake,incorrect,fault,defect,flaw,patch,本文采用同樣的錯誤關鍵詞.

4.1.4 相關性分析

本文采用Spearman 系數檢驗來分析度量體系指標與軟件缺陷的相關性.Spearman 系數檢驗能夠衡量兩個變量之間的依賴性,利用單調的方程來評價變量之間的相關性.如果兩個變量完全單調相關,那么相關系數為+1或者-1.其中,+1 表示正相關,-1 表示負相關,0 表示完全不相關.若相關系數在0.7 到1.0 之間,為強相關;0.3 到0.7 為中等相關;0 到0.3 為弱相關[26].相關性系數的絕對值越大,說明相關性越大、度量體系指標越有效.為了評估Spearman 系數的顯著性,計算p值(pvalue)來分析結果是否顯著有效.使用不同個數的*來表示顯著性值的大小等級:***代表p值<0.001,即極其顯著的統計學差異;**代表p值<0.01,即有顯著統計學差異;*代表p值<0.05,即有統計學的差異;沒有任何*表示p值>0.05,即缺乏統計學的差異.

4.2 研究結果

4.2.1 當前時間段的代碼評審過程和下一個時間段軟件缺陷的關系

為了研究開源社區評審過程度量體系的有效性,本節分析當前時間段的度量指標和下一時間段軟件缺陷的關系.首先,根據當前時間段的數據計算了當前時間段的項目中每個模塊在度量體系里的各個指標;然后,通過錯誤詞集匹配,計算下一個時間段每個模塊中的缺陷數目;最后,通過Spearman 系數檢驗來計算當前時間段的度量指標和下一時間段軟件缺陷的相關系數,得出表3.如果3 個項目的相關性結論一致,那么在第6 列標出具體的結論.如果3 個項目的相關性不一致,那么結論是不確定.

從表3 的數據可以看出:在Xbmc 和Roslyn 項目里,評審活動指標(評審次數、評審信息長度、評審時間、代碼改動行數)與軟件缺陷的相關系數都在0.4 到0.7 之間,即中等正相關;elasticsearch 項目中,評審活動指標(評審次數、評審信息長度、評審時間、代碼改動行數)與軟件缺陷的相關系數都在0.7 以上,呈高等正相關.這說明度量體系中的評審活動指標與軟件缺陷存在較強的相關性.當前時間段的評審次數越多、評審信息長度越大、評審時間越長、代碼改動行數越多,下一個時間段的模塊缺陷越多.在計算相關系數時,本文還計算了p值,分析結果是否顯著.表3 的結果表明:大多數p值都小于0.001,結果具有顯著的統計學意義.

Table 3 Relationship between current time period index and next time period module defect表3 當前時間段指標和下一個時間段模塊缺陷的相關系數

在人員分布指標中,改動者數量,評論者數量,決策者數量,少改動、少評論、少決策者的比例也和軟件缺陷成中等正相關性,相關系數基本在0.4 到0.7 之間.另外,多改動、少評論、少決策者的比例和軟件缺陷數量的相關性系數接近0.3,接近中等正相關.

從表3 可以看出:少改動、多評論、少決策者的比例與軟件缺陷數量相關系數接近在-0.1 到-0.3 之間,表現為負相關性;而多改動、少評論、少決策者的比例與軟件缺陷數量相關系數在0.2 到0.4 之間,接近中等正相關性.可以看出:開發人員并不只是通過代碼改動來參與軟件的開發,開發人員還可以通過評論和評審來對開源項目做貢獻.多改動但是評論和決策貢獻量小的開發者的比例,反而與軟件缺陷成正相關;少改動但是評論和決策貢獻量大的開發者的比例,與軟件缺陷成負相關.如果度量體系不考慮評論者和決策者,那么少改動、多評論、少決策者的比例與軟件缺陷的相關性就會被忽視掉,這說明本文在設計評估體系時考慮評審指標是合理的.

與現有工作[2,3]相比,本文提出的評審過程度量體系增加了決策者指標.為了分析決策者指標的有效性,本文分別統計只考慮改動者和評論者的度量體系、只考慮改動者的度量體系與軟件缺陷數量的關系,結果詳見表4 和表5.

Table 4 Relationship of modifier and commentator between current time period index and next time period module defect表4 只考慮改動者和評論者的當前時間段指標和下一個時間段模塊缺陷的相關系數

Table 5 Relationship of modifier between current time period index and next time period module defect表5 只考慮改動者的當前時間段指標和下一個時間段模塊缺陷的相關系數

表3 考慮了決策者的人員分布指標中,決策者數量,多改動、少評論、少決策者的比例,少改動、少評論、少決策者的比例與軟件缺陷數量都接近中等正相關.相比于表3,表4 只考慮改動者和評論者的人員分布指標里,多改動、少評論者的比例,少改動、多評論者的比例,少改動、少評論者的比例都和軟件缺陷數量接近弱相關,達不到中等相關;表5 只考慮改動者的人員分布指標的相關性無法確定.本文提出的度量指標與軟件缺陷數量存在較強的相關性.這說明了考慮決策者因素的度量體系的適用性和有效性.

4.2.2 上一個時間段的軟件缺陷數量與當前時間段的評審過程的相關性

本文進一步研究當前時間段的評審活動是否會受上一個時間段模塊缺陷的影響.探究對于上一個時間段有缺陷的模塊,開發人員是否在當前時間段的代碼評審中給了它們足夠的關注和評審,來解決它們的遺留問題.首先,根據當前時間段的數據計算了當前時間段的項目中每個模塊在度量體系里的各個指標;然后,通過錯誤詞集匹配,計算上一個時間段每個模塊中的缺陷數目;最后,通過Spearman 系數檢驗來計算當前時間段的度量指標和上一時間段軟件缺陷的相關系數,得出表6.

Table 6 Relationship between current time period index and previous time period module defect表6 當前時間段的指標和上一個時間段模塊缺陷的相關系數

從表6 的數據可以看出:3 個項目的評審活動指標(評審次數、評審信息長度、評審時間、代碼改動行數)與軟件缺陷的相關系數在0.4~0.7 之間,呈現中等正相關.這說明度量體系中的評審活動指標與軟件缺陷存在較強的相關性.上一個時間段缺陷越多的模塊,在當前時間段的評審次數越多、評審信息長度越大、評審時間越長、代碼改動行數越多.在計算相關系數時,本文還計算了p值,分析結果是否顯著.表6 的結果表明,大多數p值都小于0.001.結果具有顯著的統計學意義.

人員分布指標中,改動者數量,評論者數量,決策者數量,多改動、少評論、少決策者的比例,少改動、少評論、少決策者的比例也和軟件缺陷成中等正相關性,相關系數在0.4~0.7 之間.這說明本文的度量體系的決策者數量指標的有效性,在人員分布指標中考慮決策者數量是合理的.

為了研究是否考慮決策者,本文統計分別統計只考慮改動者和評論者的度量體系、只考慮改動者的度量體系與軟件缺陷數量的關系,結果詳見表7 和表8.

Table 7 Relationship of modifier and commentator between current time period index and next time period module defect表7 只考慮改動者和評論者的當前時間段指標和上一個時間段模塊缺陷的相關系數

Table 8 Relationship of modifier between current time period index and next time period module defect表8 只考慮改動者的當前時間段指標和上一個時間段模塊缺陷的相關系數

表6 里考慮了決策者的人員分布指標中,多改動、少評論、少決策者的比例,少改動、少評論、少決策者的比例與軟件缺陷數量相關系數在0.4 到0.7 之間,呈現較強的正相關性;相比于表6,表7 只考慮改動者和評論者的人員分布指標里,多改動、少評論者的比例,少改動、多評論者的比例,少改動、少評論者的比例和軟件缺陷數量的相關性無法確定;表8 只考慮改動者人員分布指標的相關系數絕對值基本都小于0.3.本文提出的度量指標與軟件缺陷數量存在較強的相關性.這充分說明本文考慮了決策者因素的度量體系的有效性和合理性.

5 討 論

5.1 有效性分析

本文分別從外部有效性和結構有效性的角度討論對有效性的威脅.

? 外部有效性.本文只在Github 上選取了部分項目作為數據集,因此,本文的結果可能不適用于所有開源社區.以后可以考慮分析更多GitHub 的項目或者其他開源社區項目,進一步分析評審過程度量體系的有效性;

? 結構有效性.本文爬取的數據都是Github 記錄的代碼評審活動,然而開發人員可能會通過其他方式進行代碼評審,例如當面討論或收發郵件.然而,這些方式都沒有顯式的記錄和數據.因此,本文研究的是有相應的代碼更改和評審記錄的模塊,包含項目中大部分的評審活動.另外,本文主要考慮代碼評審過程度量指標.未來考慮嘗試更多度量指標并分析其和軟件缺陷的關系,比如考慮評估代碼評審質量體系的方法以及相關指標.

5.2 啟 示

表4 中只考慮了改動者和評論者,沒有考慮決策者,結果顯示:多改動、少評論者的比例,少改動、多評論者的比例,少改動、少評論者的比例都和軟件缺陷數量接近弱相關,達不到中等相關;表5 里只考慮改動者,人員分布指標與軟件缺陷數量的相關性無法確定.而表3 中,考慮了決策者因素的度量指標與軟件缺陷數量存在較強的相關性.因此,在設計評審過程度量體系時,應該考慮決策者因素.

表3~表5 的結果顯示,有的開發人員主要通過決策來參與軟件開發.他們在傳統的指標體系中被定義為少改動者、少評論者,和軟件缺陷數量的相關性無法確定.但是在考慮了決策者因素后,他們反而因為多決策活動而成為了軟件開發的主要貢獻人員.因此,建議未來評審相關的研究考慮決策者和決策活動.

從表3 看出,一些度量指標和軟件缺陷數量至少中等正相關,包括評審次數,評審信息長度,評審時間,代碼改動行數,改動者數量,評論者數量,決策者數量,少改動、少評論、少決策者的比例.這些指標的數值越大,軟件缺陷數量越多.因此,開源項目需要重點觀察少改動、少評論、少決策者的比例等指標高的模塊,這些高風險模塊往往有更多的軟件缺陷.

6 總結與展望

在開源開發中,不同的開發人員的代碼水平參差不齊.代碼評審是保證開源項目質量的重要方式.本文提出了一個開源社區評審過程度量體系,包括評審活動指標和人員分布指標.該度量體系綜合考慮人員在代碼改動、評審決策和發表評論的活動.然后,本文分析了評審過程與軟件缺陷之間的關系.通過與不考慮決策者的度量指標進行對比分析,驗證了本文提出評審過程度量體系的有效性,說明了增加決策者相關指標的必要性.