鴉 文，楊沁梅

（中國(guó)電子科技集團(tuán)公司第二十八研究所，江蘇 南京 210007）

0 引言

測(cè)試是“使用為發(fā)現(xiàn)錯(cuò)誤所選擇的輸入和狀態(tài)的組合而執(zhí)行代碼的過程”[1-4]，代碼審查是軟件測(cè)試的手段之一，是在不執(zhí)行軟件的條件下有條理地仔細(xì)審查軟件代碼，從而找出軟件缺陷的過程。代碼審查必須依靠具有軟件系統(tǒng)開發(fā)經(jīng)驗(yàn)、編程經(jīng)驗(yàn)、測(cè)試經(jīng)驗(yàn)的技術(shù)人員集體審查[5]。進(jìn)行代碼審查的主要目的是提高軟件質(zhì)量，及早發(fā)現(xiàn)軟件缺陷，避免因這些缺陷造成更大的災(zāi)難[6]。在開發(fā)過程初期進(jìn)行軟件代碼審查非常有價(jià)值，不僅可以找出后期軟件測(cè)試階段難以發(fā)現(xiàn)或隔離的軟件缺陷，降低研發(fā)成本；同時(shí)還可以促進(jìn)開發(fā)團(tuán)隊(duì)內(nèi)部溝通和知識(shí)共享，提升團(tuán)隊(duì)開發(fā)能力。

量化管理是CMMI的主要內(nèi)容之一，量化管理使得軟件管理者擁有決策的客觀基礎(chǔ)，能在量化的范圍內(nèi)預(yù)測(cè)性能，可以有效地監(jiān)控項(xiàng)目過程，處理過程偏差的特殊原因[7-12]。

為此，可以將代碼審查過程識(shí)別為影響項(xiàng)目目標(biāo)達(dá)成的關(guān)鍵過程之一，通過建立過程性能模型和使用適當(dāng)?shù)牧炕治龇椒╗13-14]，來指導(dǎo)代碼審查活動(dòng)的策劃和實(shí)施，達(dá)到提升產(chǎn)品最終質(zhì)量的目標(biāo)。統(tǒng)計(jì)過程控制中主要利用控制圖來記錄過程質(zhì)量[15]。

1 代碼審查平臺(tái)

軟件項(xiàng)目管理過程中，組織往往缺少量化的數(shù)據(jù)支撐，從而導(dǎo)致對(duì)于有關(guān)量化的改進(jìn)目標(biāo)制定或者項(xiàng)目的量化目標(biāo)制定無從下手[16]。為此，可以通過集成開源的配置管理、代碼檢測(cè)、權(quán)限控制工具，建立代碼審查平臺(tái)來進(jìn)行在線審查和數(shù)據(jù)采集，為后續(xù)的模型建立和量化分析過程提供平臺(tái)支撐。

一種可行的代碼審查平臺(tái)設(shè)計(jì)架構(gòu)如圖1 所示。

圖1 代碼審查平臺(tái)架構(gòu)

其中：

（1）Crowd 是atlassian 公司推出的集成化組件，其實(shí)現(xiàn)和配置簡(jiǎn)單，功能齊全，用于用戶管理和授權(quán)登錄。利用此平臺(tái)可錄入代碼審查活動(dòng)相關(guān)人員信息并賦予不同的使用和管理權(quán)限。

（2）Crucible工具是一個(gè)代碼檢測(cè)工具，能檢查、注釋、編輯代碼，并記錄結(jié)果，幫助開發(fā)人員發(fā)現(xiàn)和糾正缺陷，提高代碼開發(fā)效率。代碼審查活動(dòng)主要依托共用平臺(tái)Atlassian Crucible 模塊實(shí)施。

（3）Gitlab 是一個(gè)用于倉(cāng)庫(kù)管理系統(tǒng)的開源項(xiàng)目，使用Git 作為代碼管理工具，并在此基礎(chǔ)上搭建起來的Web服務(wù)。該模塊用于瀏覽源代碼和代碼缺陷管理。開發(fā)團(tuán)隊(duì)可使用該模塊瀏覽歷史版本，也可以利用其代碼片段收集功能實(shí)現(xiàn)代碼復(fù)用、查找。該模塊非強(qiáng)制使用，由項(xiàng)目組/業(yè)務(wù)室選擇使用。

2 代碼審查觸發(fā)時(shí)機(jī)

代碼審查由項(xiàng)目軟件負(fù)責(zé)人或?qū)I(yè)/業(yè)務(wù)負(fù)責(zé)人在完成以下代碼研發(fā)和自測(cè)后組織執(zhí)行?？芍攸c(diǎn)針對(duì)以下對(duì)象進(jìn)行審查：

（1）被定義為關(guān)重件配置項(xiàng)的代碼；

（2）核心算法、主要業(yè)務(wù)邏輯、關(guān)鍵數(shù)據(jù)處理、提供對(duì)外接口的代碼；

（3）新員工產(chǎn)生的代碼；

（4）前期測(cè)試過程中問題較多的軟件代碼。

3 代碼審查

3.1 審查準(zhǔn)備

3.1.1 建立專家?guī)?/p>

項(xiàng)目研發(fā)組織首先應(yīng)建立代碼審查專家?guī)欤饕蓡T可以是組織內(nèi)各領(lǐng)域的資深程序員和各專業(yè)/業(yè)務(wù)的技術(shù)骨干。

每次代碼審查前，由各項(xiàng)目/專業(yè)/業(yè)務(wù)負(fù)責(zé)人依據(jù)被審查代碼的專業(yè)/業(yè)務(wù)類型從部門代碼審查專家?guī)熘羞x取除被審代碼編寫者之外的代碼審查人員，成立代碼審查組，并指定代碼審查組長(zhǎng)。

3.1.2 設(shè)置用戶權(quán)限

依托代碼審查平臺(tái)可以實(shí)現(xiàn)用戶的添加和權(quán)限設(shè)定，主要步驟如下：

（1）由配置管理員在Crowd 模塊中錄入人員信息（支持分組），并設(shè)定各模塊管理員和使用者角色；

（2）配置管理員將Crucible、Gitlab 模塊的權(quán)限信息與Crowd 相連，確保Crowd 模塊中的用戶信息在各個(gè)模塊中可見；

（3）各項(xiàng)目/專業(yè)/業(yè)務(wù)負(fù)責(zé)人在需使用的模塊中設(shè)定人員權(quán)限。

3.1.3 選取和提交審查代碼

代碼審查前，各項(xiàng)目/專業(yè)/業(yè)務(wù)依據(jù)第2 節(jié)選取需審查代碼（但不限于）。

3.2 執(zhí)行代碼審查

代碼審查專家在Crucible 上開展代碼審查活動(dòng)，審查重點(diǎn)為代碼整體架構(gòu)、風(fēng)格、邏輯質(zhì)量等，審查項(xiàng)及主要要求參考表1。

表1 首輪采集

具體方法：

（1）代碼審查專家登錄“l(fā)zb.cru.com:8060/cru”，打開代碼開展審核；

（2）點(diǎn)擊有問題的代碼，并輸入審查意見，點(diǎn)擊“Comment”提交。

3.3 審查問題整改歸零

（1）代碼審查后，開發(fā)人員根據(jù)代碼審查專家提出的問題對(duì)代碼進(jìn)行修改；（2）完成修改后，重新提交代碼審查；（3）代碼審查人員進(jìn)行回歸確認(rèn)。

3.4 審查結(jié)果處置

項(xiàng)目代碼審查活動(dòng)結(jié)束后，由代碼審查組長(zhǎng)匯總、分析代碼審查數(shù)據(jù)，并及時(shí)將代碼審查過程中遇到的典型編碼缺陷在開發(fā)團(tuán)隊(duì)或全部門集中宣貫，減少典型缺陷重復(fù)發(fā)生。

4 代碼審查過程性能模型建立

4.1 模型定義

代碼審查缺陷清除模型預(yù)測(cè)值為代碼審查發(fā)現(xiàn)缺陷的密度，分析確定影響部級(jí)代碼審查質(zhì)量的因子是：審查專家能力、開發(fā)人員能力和代碼審查速率。即：代碼審查發(fā)現(xiàn)缺陷的密度＝f（審查專家能力，開發(fā)人員能力，代碼審查速率）。

模型因子取值如下：

（1）審查專家能力取值：5 表示能力高，從事軟件編碼工作5 年及5 年以上；3 表示能力中，從事軟件編碼工作大于等于3 年且少于5 年；1 表示能力低，從事軟件編碼工作少于3 年。

（2）開發(fā)人員能力取值：5 表示能力高，從事軟件編碼工作5 年及5 年以上；3 表示能力中，從事軟件編碼工作大于等于3 年且少于5 年；1 表示能力低，從事軟件編碼工作少于3 年。

（3）代碼審查速率＝代碼審查代碼規(guī)模÷代碼審查總工時(shí)。

4.2 數(shù)據(jù)采集

首輪采集了21 組有效數(shù)據(jù)，見表1。

4.3 模型試算

4.3.1 正態(tài)性檢驗(yàn)

經(jīng)使用Mintab工具計(jì)算得到的審查專家能力、開發(fā)人員能力和代碼審查速率這3 個(gè)參數(shù)的正態(tài)性檢驗(yàn)結(jié)果如圖2 所示。

圖2 正態(tài)性檢驗(yàn)結(jié)果

4.3.2 相關(guān)性分析

經(jīng)使用Mintab工具計(jì)算得到的審查專家能力（x1）、開發(fā)人員能力（x2）、審查速率（x3）和代碼審查缺陷密度（Y）這4 個(gè)參數(shù)的相關(guān)性結(jié)果如圖3 所示。

圖3 相關(guān)性分析結(jié)果

4.3.3 回歸分析結(jié)果

進(jìn)一步使用Mintab工具計(jì)算，得到初步建立的模型算法，如圖4 所示。即：

圖4 回歸分析結(jié)果

代碼審查缺陷密度（個(gè)/千行）=3.583+0.076×審查專家能力-0.159×開發(fā)人員能力-1.977×代碼審查速率

4.4 基線建立

經(jīng)Mintab工具計(jì)算得到代碼審查缺陷密度概率圖如圖5 所示，計(jì)算得到的P 值大于0.05，顯示樣本數(shù)據(jù)服從正態(tài)分布。

圖5 代碼審查缺陷密度概率圖

進(jìn)一步使用控制圖檢查數(shù)據(jù)的穩(wěn)定性，如圖6 所示，數(shù)據(jù)點(diǎn)隨機(jī)地分布在中心線（即基線均值）上下，且在基線上下限之間，表明數(shù)據(jù)基本穩(wěn)定。

圖6 數(shù)據(jù)穩(wěn)定性檢查

最終獲得的基線值如圖7 所示，即代碼審查缺陷密度平均為1.921 9 個(gè)/千行代碼。

圖7 代碼審查基線值

5 結(jié)論

研發(fā)團(tuán)隊(duì)所屬組織可以根據(jù)組織對(duì)產(chǎn)品質(zhì)量的要求和團(tuán)隊(duì)實(shí)際情況，參考以上得到的代碼審查缺陷密度平均值來設(shè)定組織級(jí)代碼缺陷目標(biāo)，并使用建立的模型，依據(jù)代碼審查的代碼規(guī)模、選定的審查專家能力，計(jì)算得到代碼審查工時(shí)的估計(jì)值，并據(jù)此估計(jì)值進(jìn)行代碼審查活動(dòng)的策劃。通過所屬項(xiàng)目后續(xù)的測(cè)試、檢驗(yàn)活動(dòng)，可以再逐步分析代碼審查遺留問題的影響，并重新修正模型和目標(biāo)，進(jìn)而逐步達(dá)到通過有效代碼審查提升代碼質(zhì)量的目的。