蔣 競,吳秋迪,張 莉

(北京航空航天大學(xué) 計(jì)算機(jī)學(xué)院,北京 100191)

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

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

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

本文的主要貢獻(xiàn)包括:

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

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

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

1 背景介紹

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

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

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

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

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

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

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

2 相關(guān)研究

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

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

3 評審過程度量體系

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

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

3.1 評審活動

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

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

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

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

3.2 人員分布

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

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

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

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

? 代碼貢獻(xiàn)量

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

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

? 評論貢獻(xiàn)量

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

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

? 決策貢獻(xiàn)量

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

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

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

? 多改動、多評論、多決策者的比例: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 中給出了評審過程度量指標(biāo)的定義和描述,這些度量指標(biāo)從評審活動和人員分布兩方面詮釋了軟件評審過程中的多維屬性.

Table 1 Review process metrics表1 評審過程度量指標(biāo)

4 實(shí)證研究

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

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

4.1 研究過程

4.1.1 項(xiàng)目選擇

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

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

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

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

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

4.1.3 軟件缺陷

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

4.1.4 相關(guān)性分析

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

4.2 研究結(jié)果

4.2.1 當(dāng)前時(shí)間段的代碼評審過程和下一個(gè)時(shí)間段軟件缺陷的關(guān)系

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

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

Table 3 Relationship between current time period index and next time period module defect表3 當(dāng)前時(shí)間段指標(biāo)和下一個(gè)時(shí)間段模塊缺陷的相關(guān)系數(shù)

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

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

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

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

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

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

4.2.2 上一個(gè)時(shí)間段的軟件缺陷數(shù)量與當(dāng)前時(shí)間段的評審過程的相關(guān)性

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

Table 6 Relationship between current time period index and previous time period module defect表6 當(dāng)前時(shí)間段的指標(biāo)和上一個(gè)時(shí)間段模塊缺陷的相關(guān)系數(shù)

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

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

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

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

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

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

5 討 論

5.1 有效性分析

本文分別從外部有效性和結(jié)構(gòu)有效性的角度討論對有效性的威脅.

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

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

5.2 啟 示

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

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

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

6 總結(jié)與展望

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