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

蔣 競,吳秋迪,張 莉

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

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

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

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

本文的主要貢獻包括:

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

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

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

1 背景介紹

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

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

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

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

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

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

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

2 相關研究

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

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

3 評審過程度量體系

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

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

3.1 評審活動

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

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

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

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

3.2 人員分布

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

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

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

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

? 代碼貢獻量

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

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

? 評論貢獻量

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

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

? 決策貢獻量

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

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

各種類型的人員并不是完全獨立的,評審過程中的開發(fā)人員可能同時扮演幾種角色.為了準確地分析評審過程里的人員組成,需要根據(jù)不同的貢獻量將人員進行劃分,并將模塊中不同類型人員的比例作為度量指標.文獻[2,3]以0.05 為閾值,按照貢獻量劃分開發(fā)人員的角色.類似的,本文也按貢獻量來劃分主要、次要貢獻者.在一個模塊中,如果一個人某個方面的貢獻量比例大于等于0.05,則稱他是這個方面的主要貢獻者.根據(jù)人員在改動、評論或者決策的貢獻量比例來給他們劃分角色.例如一個人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 的真實數(shù)據(jù)來進行實證研究.如圖2 所示,參考Patanamon 的論文[23],本文把數(shù)據(jù)分成3 部分:上一個時間段、當前時間段、下一個時間段.每個時間段都是6 個月.上一個時間段的數(shù)據(jù)用來計算之前的軟件缺陷;當前時間段的數(shù)據(jù)用來計算當前的評審過程指標;下一個時間段的數(shù)據(jù)用來計算評審后的軟件缺陷.然后,基于度量評估體系對原始數(shù)據(jù)進行加工處理,計算得出各種指標,最后使用相關性分析方法研究評審過程度量指標與軟件缺陷的關系.相關系數(shù)的絕對值越大,說明度量指標和軟件缺陷數(shù)量越相關,度量指標越有效.

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

4.1 研究過程

4.1.1 項目選擇

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

Fig.2 Data partition圖2 數(shù)據(jù)劃分

4.1.2 數(shù)據(jù)收集

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

Table 2 Project data statistics表2 項目數(shù)據(jù)統(tǒng)計

4.1.3 軟件缺陷

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

4.1.4 相關性分析

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

4.2 研究結果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 討 論

5.1 有效性分析

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

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

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

5.2 啟 示

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

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

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

6 總結與展望

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