頭圖

現代代碼審查:Google案例研究

LeapFE

摘要

使用基于工具的輕量級代碼檢查代碼更改(又名現代代碼審查)已成為廣泛的規范,應用于各種開源和產業系統。在本文中,我們對Google的現代代碼審查進行了探索性研究。 Google很早就引入了代碼審查并經過多年的發展;我們的研究揭示了為什么Google引入了這種做法并分析了當前的狀態,經過數十年的代碼變更和數百萬條代碼審核。通過12次訪談,對44位受訪者的調查以及分析的900萬條已審核變更的審核日志,我們調查了Google進行代碼審查的動機,當前做法,以及開發人員的滿意度和挑戰。

1.引言

對等代碼審查,是除了作者以外的開發者們對源代碼進行手動檢查,被認為是對提高軟件項目質量的一種有價值的工具。在 1976年,Fagan正式制定了高度結構化的代碼審查流程——代碼檢查。多年來,研究人員提供了有關代碼檢查的優勢的證據,特別是在發現缺陷上,但麻煩的是費時,這種方法的同步性特點阻礙了它在實踐中的推廣?,F今,大多數組織都采用更輕量級的代碼審查實踐來限制檢查效率低下?,F代代碼審查是(1)非正式(與Fagan風格相反),(2)基于工具的,(3)異步,(4)聚焦于審查代碼更改。

一個開放的研究挑戰是:在這種新穎的背景下,了解哪些實踐代表了寶貴而有效的審查方法。 Rigby和Bird定量分析了來自跨領域軟件項目以及組織的代碼審查數據,發現五個高度趨同的方面,他們猜想其他的項目也有這個規律性。Rigby和Bird的分析基于有價值的廣泛的觀點(分析了多個來自不同的環境的項目)。對于由Basili倡導的知識實證體系的發展,同樣重要的是要考慮對單個案例進行分析的集中和縱向的觀點。本文擴展了Rigby和Bird的工作,著重于審查實踐和特色,主要是:在Google成立,一家公司擁有數十年的代碼審查的歷史和大量的每日審查借鑒。本文可以(1)對從業人員規定進行代碼審查和(2)吸引研究人員想了解和支持這一新穎過程的人。

從Google非常早期的歷史開始,代碼審查就已經成為軟件開發中必不可少的一部分;因為它很早就引入了,已經成為了Google文化的一個核心部分。在Google,代碼審查的過程和工具經過反復完善了十多年,應用在每天全球數十個辦公室中,超過25,000名開發人員的超過20,000行源代碼的更改。

我們以探索性調查形式進行分析聚焦于代碼審查的三個方面,并擴展了Rigby和Bird的成果:(1)驅動代碼審查的動機,(2)當前實踐,以及(3)開發人員對代碼審查的感受,專注于特定審查遇到的挑戰(審核過程中的中斷)和滿意度。我們的研究方法結合了來自多個數據源的輸入:對Google開發人員進行12次半結構化的訪談;一個內部調查,發送給了最近做個變更審查的工程師,并收到44條回復;一組來自兩年間的Google代碼審查工具產生的900萬條評論的數據。

我們發現:相比其他情況,Google的流程明顯更輕松,基于一位審閱者,快速迭代,小更改,以及集成緊密代碼審查工具。由于圍繞代碼審查發生的交互是復雜的,中斷審查仍然存在。不過,開發人員認為此過程很有價值,確信當規模很大的時候,可以很好地發揮作用,并且,進行這個過程有若干原因,也取決于作者與審查者之間的關系。最后,我們發現關于使用代碼審查工具,不僅可以協作審查,而且還有個一個很重要的發現:代碼審查可以作為一種教學工具。

2.背景和相關工作

我們描述了文獻研究中的審查過程,然后我們詳細介紹這些融合代碼審查的做法流程。

2.1 代碼審查過程和情景

代碼檢查。軟件檢查是第一個正式的代碼審查流程。這個高度結構化的過程涉及計劃,概述,準備,檢查會議,返工和跟進。代碼檢查的目標是在同步檢查會議中發現缺陷,作者和審稿人坐在同一會議室內來檢查代碼更改。 Kollanus和Koskinen匯編了有關代碼檢查的最新文獻調查研究。他們發現絕大多數關于代碼檢查的研究本質上是經驗性的。代碼檢查作為一種發現缺陷的技術的整體價值和促使檢查者讀代碼的價值存在共識??傮w而言,與Internet的普及和異步代碼審查流程的增長,自2005年以來,代碼檢查的研究有所下降。

通過電子郵件進行異步審查。直到2000年代后期,大多數大型OSS項目都采用一種遠程異步審查的形式,這依賴于補丁發送的通訊渠道,如郵件列表和問題跟蹤系統。在這種情況下,項目成員評估貢獻的補丁程序并通過這些渠道請求修改。當補丁被認為質量足夠高時,核心開發人員會將其提交給代碼庫。受信任的提交者可能具有提交到審查過程,而不是進行提交前的審查。 Rigby等人,是最早在這種環境下進行廣泛工作的人之一;他們發現,這種類型的審查“與[代碼檢查]幾乎沒有共同點,只是相信同行會有效地發現軟件缺陷” 。 Kononenko等人,分析了這種情況,并且發現審查響應時間和接受程度和社會因素相關,例如,審查者的工作量和改變作者的經驗,這些是代碼檢查所無法反映的。

基于工具的審查。為了使修補程序審查的過程結構更加合理,OSS和工業設置中出現了幾種工具。這些工具支持審閱過程的持久工作:(1)補丁的作者將其提交給代碼審閱工具,(2)審閱者可以看到建議代碼與更改的差異,(3)可以與作者和其他審稿人就特定的話題展開討論,然后(4)作者可以提出修改意見,以解決評審者的意見。此反饋周期將持續到每個人都滿意或補丁被丟棄為止。不同的項目使用了他們的工具來支持他們的過程。 Microsoft使用CodeFlow,該工具跟蹤每個人(作者或審閱者)的狀態以及他們在進程中的位置(簽名,等待,審閱); CodeFlow不會阻止作者未經批準而提交更改,并支持在評審線程中聊天。 Google的Chromium項目(以及其他幾個OSS項目)依賴于外部可用的Gerrit;在Chromium中,只有經過審閱者的明確批準并自動確認更改不會破壞構建,更改才會合并到master分支中。在Gerrit中,未分配審查者也可以發表評論。 VMware開發了開源的ReviewBoard,它將靜態分析集成到審查過程中。這種集成依賴于變更作者手動請求分析,并且已經證明可以提高代碼審查的質量。 Facebook的代碼審查系統Phabricator,使審查者可以“接管”更改并自行提交,并提供了掛鉤以進行自動靜態分析或持續的構建/測試集成。

在基于工具審查的背景下,研究人員調查了代碼更改接受或響應時間與更改后的代碼和作者的特征之間的關系,以及審閱者之間的協議。 根據工業和OSS開發人員的意見,還進行了定義什么構成良好的代碼審查。

基于分叉模式的開發模型。在GitHub上,拉請求的過程中,開發人員想要對現有的git倉庫進行更改,就要對其fork進行更改。在發出拉請求后,會出現在拉請求的列表中展示項目中的問題,任何可以看到該項目的人都可以看到。 Gousios等人對拉請求集成者和貢獻者的實踐和碰到的問題進行了定性研究,發現與基于工具的代碼審查有類似的方法。

2.2 代碼審查中的融合實踐

Rigby和Bird提出了第一項也是最重要的工作,這些工作試圖跨幾個代碼審查過程和上下文確定融合的實踐。 他們考慮了使用基于電子郵件審查的OSS項目,使用Gerrit的OSS項目,使用基本代碼審查工具的AMD項目以及使用CodeFlow的Microsoft。 他們分析了這些項目的過程和數據,以描述多個角度,例如迭代開發,審查者選擇和審查討論。 他們確定了所有已考慮項目都融合到的五種現代代碼審查實踐(表1)。 我們將使用其ID(例如CP1)來引用這些做法。 基本上,他們在快速,輕量級過程(CP1,CP2,CP3)方面達成了一致,很少有人參與(CP4)進行小組問題解決(CP5)。

id融合實踐
CP1當時同行審查遵循輕量級,靈活的流程
CP2審查要提早(在提交更改之前),快速且頻繁地進行
CP3變更范圍很小
CP4兩名審查者找大量的缺陷
CP5審查已從發現缺陷活動變為小組解決問題活動

3.方法論

本節描述了我們研究的問題和背景;它還概述了我們的研究方法及其局限性。

3.1 研究的問題

這項研究的總體目標是調查Google的現代代碼審查,這一過程涉及成千上萬的開發人員,并且經過了十多年的改進。 為此,我們進行了探索性調查,圍繞三個主要研究問題進行了結構設計。

RQ1:Google進行代碼審查的動機是什么?Rigby和Bird發現動機是現代代碼審查的融合特征之一(CP5)。 在此可以了解,動機和期望推動了Google的代碼審查。 特別是,我們既考慮了引入現代代碼審查的歷史原因(因為Google是最早使用現代代碼審查的公司之一),也考慮了當前的期望。

RQ2:Google的代碼審查實踐是做什么? Rigby和Birdregard根據流程(CP1),速度和頻率(CP2),分析變更的大?。–P3)和審閱者數量(CP4)來執行流程本身。 我們對Google的這些方面進行了分析,以調查與以前的研究相比,對于具有更長代碼審查歷史,明確文化和大量審查記錄的公司來說,同樣的發現是否成立。

RQ3:Google開發人員如何看待代碼審查?最后,在我們的最后一個研究問題中,我們有興趣了解Google開發人員如何看待其公司中已實施的現代代碼審查。為了更好的理解實踐(因為感知驅動行動)和指導未來的研究,這個探索很必需。我們聚焦于兩方面:一些特定的審查,比如:開發人員有中斷審查的經歷;在面臨一些挑戰時開發人員對審查是否滿意。

3.2 研究的背景

我們簡要描述了關于我們方法論的研究背景。 有關Google代碼審查過程和工具的詳細說明,請參見第5.1節。

Google的大多數軟件開發都在一個整體的源代碼存儲庫中(mono-repo),通過內部版本控制系統訪問。 由于Google代碼審查是必需的,因此,每次向Google源代碼控制系統提交代碼,都先要使用CRITIQUE進行代碼審查,CRITIQUE是一個內部開發的,集中的,基于Web的代碼檢查工具。 開發工作流程基于Google的整體代碼庫,包括代碼審查過程,是非常統一的。就像第2節中描述的工具一樣,CRITIQUE允許審查者看到提議更改代碼和開始討論前明確的代碼行處。CRITIQUE提供了大量的登錄功能;記錄開發者使用該工具的交互(包括打開工具,查看差異,創建評論和接受更改)。

3.3 研究的方法

為了回答我們的研究問題,我們采用定性和定量相結合的方法,該方法結合了以下幾種來源的數據:在與Google從事軟件開發工作的員工進行的半結構化訪談,來自代碼審查工具的日志以及對其他員工的調查。我們使用訪談作為一種工具來收集有關進行代碼審查(RQ1)動機的多樣性(與頻率相對比)的數據,并激發開發人員對代碼審查及其挑戰(RQ3)的理解。 我們使用CRITIQUE的日志來量化和描述當前的審查實踐(RQ2)。最后,我們使用調查來確認訪談(RQ1)中出現的代碼審查的多種動機,和激發開發人員對過程的滿意度的因素。

會談。我們與選定的Google員工進行了一系列面對面的半結構化訪談,每次訪談大約需要1個小時。最初的可能參加者是使用滾雪球采樣法來選擇的,首先是論文作者所知道的開發人員。從此庫中,選擇參與者以確保團隊的分散,技術領域,工作角色,公司內部的時間長度以及在代碼審核過程中的角色。訪談腳本包括有關代碼審查的動機,最近審查/撰寫的變更,以及最佳/最差審查經歷的問題。 在每次訪談之前,我們都會回顧參與者的審查歷史,并找到要在訪談中會討論的更改; 我們選擇這些更改,是根據互動次數,參與對話的人數,以及是否有很多令人驚訝審查點評。在訪談的觀察部分中,要求參與者在審閱即將發生的變更時思考,并提供一些明確的信息,例如開始審閱的切入點。 訪談一直持續到達到飽和,并且訪談提出了大致相似的概念。 總體而言,我們對從Google工作1個月到10年(平均5年),軟件工程和站點可靠性工程的員工進行了12次面試。他們包括技術主管,經理和個人貢獻者。每次訪談涉及三到四個人:參與者和2-3個受訪者(其中兩個是本文的作者)。采訪由一名采訪者實時轉錄,而另一名采訪者提出問題。

采訪數據的開放編碼。為了確定采訪數據中出現的廣泛主題,我們進行了一次開放編碼。 兩位作者討論了訪談筆錄,以確立共同的主題,然后將其轉換為編碼方案。 然后,另一位作者對討論的注釋進行了封閉編碼,注釋是對確認的主題。我們對其中不止一個采訪進行了迭代,直到我們就該計劃達成協議。 我們還跟蹤了上下文(審稿人與作者之間的關系)中提到的這些主題。問題設計和分析過程的結合意味著我們可以討論結果中的穩定主題,但不能有意義地討論發生的相對頻率。

審查數據的分析。我們定量的分析數據,數據是代碼審查過程中使用CRITIQUE產生的日志。我們主要關注Rigby和Bird發現的融合實踐(CP)相關的指標。為了方便對比,我們不考慮沒有審查者的更改,因為我們對有明確代碼審查過程的更改感興趣。我們將“審閱者”視為批準代碼更改的任何用戶,而不論更改作者是否明確要求他們進行審閱。我們使用基于名稱的啟發式的方法來自動化流程產生的更改。我們專門關注Google主要代碼庫中發生的更改。我們還排除了在研究時尚未落實的更改,以及我們的差異工具報告的源碼零行變化量的更改,例如,僅修改二進制文件的更改。在Google,平均每個工作日,提交了約20,000個符合上述過濾條件的更改。 我們的最終數據集包括2014年1月至2016年7月,由25,000多名作者和審閱者創建的符合這些標準的大約900萬項更改,以及從2014年9月至2016年7月之間的所有更改中收集的大約1300萬條審查評論。

調查。我們創建了一個在線調查表,并發送給了98位最近提交了代碼更改的工程師。代碼更改已經過審核,因此我們定制了調查表,以詢問受訪者如何看待代碼審核,關于他們最近的特定更改;這種策略使我們可以減輕召回偏見,但仍可以收集全面的數據。 該調查包括三個關于收到的評論的價值的Likertscale問題,一個關于評論對其更改影響的多項選擇(基于訪談產生的期望)和一個可選的“其他”回答,以及一個開放式- 最終提出質疑,以引起受訪者對所收到的評論,代碼評論工具和/或整個過程的意見。 我們收到了44份有效的調查問卷答復(45%的答復率,在軟件工程研究中被認為很高了)。

3.4 有效性和局限性的威脅

我們描述了研究方法所帶來的對有效性和工作成果局限性的威脅,以及為緩解這些挑戰所采取的行動。

內部有效性——可信度。關于評論數據的定量分析,我們使用啟發式方法從定量分析中濾除機器人撰寫的更改,但這些啟發式方法可能允許某些機器人撰寫的更改; 我們對此進行了緩解,因為我們僅包括具有人工審核者的由機器人撰寫的更改。關于定性調查,我們使用了開放式編碼來分析受訪者的答案。該編碼可能會受到編寫該編碼的作者的經驗和動機的影響,盡管會通過讓多個編碼人員參與來減輕這種偏見。決定參加我們的訪談并自由選擇調查的員工決定這樣做,從而引入了自我選擇偏見的風險。 因此,對于不選擇參與的開發人員而言,結果可能會有所不同;為減輕此問題,我們將訪談和調查中的信息相結合。 此外,我們使用雪球抽樣方法來確定要面試的工程師,這有抽樣偏差的風險。盡管我們試圖通過面試具有各種工作角色和職責的開發人員來減輕這種風險,但我們訪談的開發人員可能有其他因素在整個公司中并不適用。 為了減輕主持人的接受偏見,參與定性數據收集的研究人員不屬于CRITIQUE團隊。 社會可取性偏見可能已經影響了答案,使其更適合Google文化。 但是,在Google鼓勵人們批評和改進發現的工作流程,從而減少這種偏見。 最后,我們沒有采訪與專家評審員(例如安全評審)進行交互的研究科學家或開發人員,因此我們的結果偏向于一般開發人員。

通用性——可移植性。我們的結果可能無法推廣到其他情況,而是我們對多年實踐和數百萬次細化檢查后,仍會發生的多種多樣的做法和審查中斷感興趣。鑒于基本代碼檢查機制在多個公司和OSS項目中的相似性, 有理由認為,如果審查過程達到相同的成熟度并使用可比較的工具,則開發人員將具有類似的經驗。

4.結果:動力

在我們的第一個研究問題中,我們首先要研究導致這一過程的原因,從而尋求理解開發人員在Google進行代碼審查時的動機和期望。

4.1 一切如何開始

Google的代碼審查最早是由第一批員工之一引入的; 本文的第一作者采訪了該員工(以下簡稱 E),以更好地理解代碼審查及其演變的最初動機。E 解釋了代碼審查引入的主要推動力是:迫使開發人員編寫其他開發人員可以理解的代碼 ; 這被認為很重要,因為代碼必須作為未來開發人員的老師。Google在代碼審查中的引入標志著從研究代碼庫(已優化為快速原型開發)向生產代碼庫的過渡,在此基礎上考慮未來工程師閱讀源代碼。代碼審查也被認為能夠確保不止一個人熟悉每一段代碼,從而增加了知識在公司中的駐留機會。

E 重申了這樣一個概念,即盡管審閱者發現錯誤是很棒的,但在Google引入codereview的首要原因是為了提高代碼的可理解性和可維護性。但是,除了最初進行代碼審查的教育動機外,E 解釋說,開發人員的三個其他好處很快就在內部對開發人員變得顯而易見:檢查樣式和設計的一致性;確保足夠的測試;通過確保沒有任何開發人員可以在沒有監督的情況下提交任意代碼來提高安全性。

4.2 目前的期望

通過對訪談數據進行編碼,我們確定了Google開發人員期望從代碼審查中獲得的四個關鍵主題:教育,維護規范,把關事故預防。 教育從代碼審查中學習或學習,并與引入代碼審查的最初原因保持一致; 規范是指組織對自由選擇的偏好(例如格式或API使用模式); 網守涉及圍繞源代碼,設計選擇或其他工件的邊界的建立和維護; 事故是指引入錯誤,缺陷或其他與質量相關的問題。

這些是審查過程中的主要主題,但是代碼審查也用于追溯歷史。開發人員在審查過程完成后對其進行評估;代碼審查可以瀏覽歷史記錄 代碼更改的內容,包括發生了什么注釋以及更改如何演變。 我們還注意到開發人員使用代碼回顧歷史來了解錯誤的引入方式。 從本質上講,代碼審查使將來的變更審核成為可能。

在我們的調查中,我們進一步驗證了這種編碼方案。 他們可以選擇四個主題中的一個或多個主題和/或自己撰寫。 較早確定的四個主題中的每個主題都是在特定代碼審查的背景下由8至11個受訪者選擇的,因此,可以更加確信上述編碼方案與開發人員對代碼審查價值的理解相一致。

盡管這些期望可以覆蓋以前在Microsoft [4]上獲得的期望,但正如我們的參與者所解釋的那樣,Google的主要重點是教育以及代碼的可讀性和可理解性,這與歷史動因相吻合。 因此,關注點與Rigby和Bird的關注點不一致(即,小組解決問題的活動)[33]。

發現1. Google進行代碼審查的期望并不以解決問題為中心。 Google引入審核,目的是確保代碼的可讀性和可維護性。 當今的開發人員除了維護規范,跟蹤歷史記錄,保護措施和預防事故外,還從教育角度進行了了解。發現缺陷受到歡迎,但不是唯一的重點。

如前所述,在對訪談筆錄進行編碼時,我們還跟蹤了提到主題的評論上下文,我們發現這些不同主題的相對重要性取決于作者與評論者之間的關系(圖1)。例如,維護工程師與具有不同資歷的工程師(項目負責人,專家可讀性審閱者或“新”團隊成員)之間的規范沖突,而與同伴或其他團隊相比則少一些,而看門人和事故預防則是主要的。具有廣泛的價值,并包含多種不同的關系。

圖1. 關系圖,描述了哪些評論期望主題主要出現在特定作者/評論者上下文中。

發現2.對Google進行特定代碼審查的期望取決于作者與審查者之間的工作關系。

5.結果:實踐

在我們的第二個研究問題中,我們描述了代碼重審過程,并將其定量方面的內容與先前工作中發現的趨同做法進行了比較[33]。

5.1 描述審查過程

Google的代碼審查與兩個概念相關:所有權和可讀性。 我們首先介紹它們,然后描述審閱過程的流程,然后得出內部審閱工具CRITIQUE與其他審閱工具不同的特點。

所有權。Google代碼庫以樹結構排列,其中每個目錄都由一組人員明確擁有。 盡管任何開發人員都可以提議對代碼庫的任何部分進行更改,但是相關目錄(或父目錄)的所有者必須在提交更改之前對其進行審核和批準; 甚至目錄所有者也要在提交之前檢查其代碼。

可讀性。Google定義了一個稱為可讀能力的概念,該概念很早就引入了,以確保代碼庫中的代碼風格和規范保持一致。 開發人員可以使用特定語言獲得可讀性認證。 為了應用可讀性,開發人員將更改發送給一組有可讀能力的審閱者。 一旦這些審閱者確信開發人員了解某種語言的代碼風格和最佳實踐,便會為開發人員授予該語言的可讀性。 每次更改都必須由具有所使用語言可讀性證明的人員編寫或審閱。

代碼審查流程。審查流程與評論緊密結合,其工作方式如下:

1。 創建:作者開始修改,添加或刪除某些代碼; 一旦準備好,他們就會進行更改。

2。 預覽:作者然后使用CRITIQUE來查看更改的差異,并查看自動代碼分析器的結果(例如,來自Tricorder [36])。 準備就緒后,作者將更改發送給一個或多個審閱者。

3。 評論:審閱者可以在Web UI中查看差異,并隨時起草評論。 程序分析結果(如果存在)也對審閱者可見。未解決的評論顯示為變更作者必須解決的操作項目。已解決的評論包括可選或信息性評論,可能不需要變更作者采取任何行動。

4。 解決反饋:作者現在可以通過更新更改或通過回復評論來處理注釋。更新更改后,作者將上載新快照。 作者和審閱者可以查看任意一對快照之間的差異,以了解發生了什么變化。

5。 批準:解決所有評論后,評論者會批準該更改并將其標記為“ LGTM”(對我來說很好 Looks Good To Me)。 要最終進行更改,開發人員通常必須至少獲得一名審閱者的批準。通常,只需一名審閱者即可滿足上述所有權和可讀性要求。

我們嘗試量化“輕量級”審閱的方式(CP1)。 我們通過檢查變更作者郵寄了一組可解決以前未解決的注釋的評論來衡量評論中來回的次數。我們假設一個迭代對應于一個作者解決某個評論的一個實例; 零重復意味著作者可以立即提交。我們發現所有更改中有80%以上最多涉及解決評論的重復。

建議審閱者。要確定最佳的人來重新審閱更改,CRITIQUE依靠一種工具來分析變更并建議可能的審閱者。 此工具確定滿足更改中所有文件的審閱要求所需的最小審閱者集。 請注意,通常只需要一名審閱者,因為更改通常是由擁有文件查詢所有權和/或可讀權的人創作的。 該工具對最近編輯和/或審閱所包含文件的審閱者進行優先級排序。 由于尚未建立新的團隊成員,因為他們尚未建立審核/編輯歷史記錄,因此已明確添加為他們。 未分配的審閱者還可以對更改發表評論(并可能批準)。尋找審閱者的工具支持通常僅在文件更改超出特定團隊的情況下才需要。 在一個團隊內,開發人員知道向誰發送更改。 為了將可能發送給團隊中任何人的更改,許多團隊使用一種系統,該系統將循環發送到團隊電子郵件地址的審閱分配給配置的團隊成員,同時考慮到審閱負載和休假。

代碼分析結果。CRITIQUE將代碼分析結果顯示為注釋以及人工注釋(盡管顏色不同)。分析人員(或審閱者)可以提供建議的編輯,這些編輯可以被提議,也可以通過評論應用于變更。 為了在更改提交之前審核更改,Google的開發還包括預提交掛鉤:檢查失敗需要開發人員顯式覆蓋以啟用提交的地方。 提交前檢查包括基本的自動樣式檢查和運行與變更相關的自動測試套件。 所有預提交檢查的結果在代碼查看工具中可見。 通常,會自動觸發預提交檢查。 這些檢查是可配置的,以便團隊可以強制實施特定于項目的不變量,并自動將電子郵件列表添加到更改中,以提高意識和透明度。 除了預先提交結果外,CRITIQUE還可以通過Tricorder [36]顯示各種自動代碼分析的結果,這些分析可能不會阻止提交更改。 分析結果包括簡單的樣式檢查,更復雜的基于編譯器的分析通過以及特定于項目的檢查。 目前,Tricorder包括110個分析儀,其中5個是用于數百次附加檢查的插件系統,總共可分析30多種語言。

發現3. Google代碼審核過程與輕量級和靈活的融合做法保持一致。 但是,與其他研究過的系統相比,所有權和可讀權是明確的,并且起著關鍵作用。 審閱工具包括審閱者推薦和代碼分析結果。

5.2 量化審核流程

我們復制了Rigby和Bird發現的CP2-4的定量分析,以便將這些實踐與Google融合的特征進行比較。

審查頻率和速度。Rigby和Bird發現快節奏的迭代開發也適用于現代代碼審查:在他們的項目中,開發人員的工作間隔非常短。 為了找到答案,他們分析了評論的頻率和速度。

在Google,就頻率而言,我們發現處于中位數上的開發者每周大約進行3次更改,而80%的開發者每周進行少于7次更改。 同樣,開發人員每周審核的變更中位數為4,而80%的審閱者每周審核的變更少于10。 在速度方面,我們發現開發人員必須等待對其更改的初步反饋,對于較小的更改,平均時間少于一小時,對于較大的更改,平均時間少于5小時。 整個審閱過程的總體(所有代碼大?。┲兄笛舆t小于4小時。 這比Rigby和Bird [33]報告的平均批準時間要低得多,AMD的批準時間中位數為17.5小時,Chrome OS為15.7小時,三個Microsoft項目為14.7、19.8和18.9小時。 另一項研究發現,微軟批準的平均時間為24小時[14]。

審查規模。Rigby和Bird認為,只有通過較小的變更來審查并隨后分析審查規模,才能實現快速審查時間。在Google,正在考慮的更改中,超過35%僅修改一個文件,而大約90%的修改少于10個文件。超過10%的更改僅修改一行代碼,而修改的行數的中位數為24。更改位數的中位數顯著低于Rigby和Bird對AMD(44行),Lucent(263行)和Bing等公司的報告。 ,Microsoft的Office和SQLServer(在這些界限之間的某個位置),但符合開放源代碼項目中的更改大小[33]。

審查者和評論的數量。甚至在經過深入研究的代碼檢查中,研究人員的最佳人數一直存在爭議[37]。 Rigby和Bird調查了所考慮的項目是否收斂到了類似數量的參與評審人員。 他們發現這個數字是兩個,無論是否明確邀請了審閱者(例如,在Microsoft項目中,邀請的中位數最多為4個審閱者),或者是否公開廣播了更改以進行審閱[33]。

相比之下,在Google中,只有不到25%的更改擁有多于一名審閱者,而超過99%的更改最多具有五名審閱者,中位審閱者人數為1。較大的更改通常平均會擁有更多的審閱者。 但是,即使平均變化非常大,平均也需要不到兩名審稿人。

Rigby和Bird還發現“當活躍于[超過2]位審稿人時,有關更改的評論數量最少” [33],并得出結論,兩名審稿人發現缺陷的最佳數量。 在Google,情況有所不同:審閱人數越多,對更改的評論平均數就越多。 此外,每次更改的平均注釋數隨行數的變化而增加,對于大約1250行的更改,每個更改的最高注釋數為12.5。 大于此的更改通常包含自動生成的代碼或較大的刪除,從而導致平均注釋數較低。

發現4.與先前調查的其他項目相比,Google的代碼審查已將審查過程融合到一個過程中,該過程的審查速度顯著加快且變更幅度較小。 此外,與其他項目中的兩名審閱者相比,一名審閱者通常被認為足夠。

6.結果:開發人員的看法

我們最后一個研究問題是通過Google的代碼審查來調查開發人員的挑戰和滿足感。

6.1 Google的代碼審查中斷

以前的研究調查了整個審查過程中的挑戰[4,26],并提供了令人信服的證據,這也被我們作為工程師的經驗所證實,理解要審查的代碼是一個主要障礙。 為了拓寬我們的經驗知識體系,我們在這里集中討論特定審查(“審查中斷”)中遇到的挑戰,例如延誤或分歧。

對我們的訪談數據的分析提出了五個主要主題。 前四個主題認為審查中斷在過程中的相關因素有:

距離:受訪者從兩個角度感知代碼審閱的距離:地理(即作者與審閱者之間的物理距離)和組織(例如不同團隊或不同角色之間的物理距離)。這兩種類型的距離都被認為是導致審閱過程延遲或導致誤解的原因。

社會互動:受訪者認為代碼審閱中的交流有可能從兩個方面導致問題:措辭和權力。 措辭是指有時作者對評論發表敏感的事實。 對評論的情感分析提供了證據,表明帶有負面語氣的評論不太可能有用[11]。 權利是指使用代碼審查過程來誘使他人改變自己的行為; 例如,拖延審核或保留批準。 措辭或權利在審查中,可能會使開發人員對檢查過程感到不舒服或沮喪。

審查主題:訪談提到了關于代碼審查是否是重新審查某些方面的最合適上下文(尤其是設計審查)的分歧。 這導致期望值不匹配(例如,某些團隊希望大多數設計在第一次審閱之前完成,其他團隊希望在審閱中討論設計),這可能導致參與者之間以及過程中產生摩擦。

背景:受訪者讓我們看到,由于不知道是什么導致了這種變化,所以會產生誤解; 例如,如果變更的理由是解決生產問題的緊急解決方案或“有個不錯的改進”。 預期結果的不匹配會導致延遲或沮喪。

最后一個主題是工具本身:

定制化:一些團隊對代碼審查有不同的要求,例如,關于需要多少審查者。 這是技術上的審查中斷,因為批評中并不總是支持任意定制,并且可能引起對這些政策的誤解。 根據反饋,CRITIQUE最近發布了一項新功能,該功能允許更改作者要求所有審閱者簽名。

6.2 滿意度和時間投入

為了了解已確定問題的重要性,我們使用了調查的一部分來調查代碼審查是否總體上被認為是有價值的。

我們發現(表2)在Google內部代碼審查被普遍認為是有價值和有效的–所有受訪者都同意代碼審查很有價值的說法。我們對CRITIQUE進行的內部滿意度調查反映了這種觀點:97%的開發人員對此感到滿意。

在特定變化的背景下,情緒變化更大。最不滿意的答復與很小的更改(1個字或2行)或與實現某些其他目標所需的更改(例如,從源代碼的更改觸發過程)相關。但是,大多數受訪者認為,他們所做的更改的反饋量是適當的。在這3個中,有8位受訪者認為注釋無濟于事,并指出,所審查的更改是小的配置更改,對代碼審核沒有影響。只有2位受訪者表示評論中有bug。

bad good
對于此更改,審核過程很好地利用了我的時間24141113
總的來說,我認為Google的代碼審查很有價值0001430
對于此更改,反饋量為223450

表2. 用戶滿意度調查結果

為了根據滿意度對答案進行情境化,我們還調查了開發人員花費在審閱代碼上的時間。為了準確量化審閱者所花費的時間,我們跟蹤了開發人員與CRITIQUE的互動(例如,打開選項卡,查看了差異,評論,批準了更改),以及其他工具來估算開發人員每周花費多長時間來審核代碼。我們將開發人員交互的順序分組為一定的時間段,將“審閱會話”視為與變更提交者以外的其他開發人員進行的,與同一未提交變更相關的交互順序,每次相隔不超過10分鐘。 從2016年10月開始的五周內,所有審核會話所花的總小時數,然后計算每周每位用戶的平均值,過濾出我們在過去五周內都沒有數據的用戶。 我們發現開發人員平均花費3.2(平均每周2.6個小時)來審查更改。 與OSS項目的6.4小時/周的自我報告時間相比,這個數字很低[10]。

發現5.盡管經過了多年的改進,但Google的代碼審查仍面對審查中斷。 這些主要與評論周圍發生的互動的復雜性有關。 但是,開發人員強烈認為代碼審查是一個有價值的過程,開發人員每周花費大約3個小時進行審查。

7.討論

我們討論了這項調查中出現的主題,這些主題可以啟發從業人員建立代碼審查流程,并激發研究人員在未來的調查中。

7.1 真正輕量級的過程

現代代碼審查的誕生是它減輕了繁瑣的代碼檢查的負擔[4]; 實際上,Rigby和Bird在他們對整個系統的調查中都證實了這一特征(CP1)。 在Google,代碼審查已匯聚到一個更加輕量級的過程,開發人員發現該過程既有價值又可以很好地利用他們的時間。

Google的審查時間中位數比其他項目要短得多。 我們假定這些差異是由于Google在代碼審查方面的文化(嚴格的審查標準和對快速審閱時間的期望)。 此外,審稿人人數也有很大差異(其中一個在Google中,而其他兩個在其他項目中);我們認為擁有一名審閱者可以使審閱變得快速而輕便。

審閱時間短和審閱者人數少可能是由于代碼審閱是開發人員工作流程中必不可少的一部分;它們也可能源于小的更改。 OSS項目的中位數變化范圍從11到32行變化,具體取決于項目。 在公司中,此更改大小通常較大,有時高達263行。 我們發現Google的更改大小與OSS更接近:大多數更改很小。變更的大小分布是代碼審查過程質量的重要因素。 先前的研究發現,隨著更改大小的增加,有用評論的數量會減少,審閱延遲會增加。 大小也會影響開發人員對代碼審查過程的理解; Mozilla投稿人的調查發現,開發人員認為與大小相關的因素對審核延遲的影響最大。 Google確認變更大小與評論質量之間的相關性,并強烈鼓勵開發人員進行小的增量更改(大刪除和自動重構除外)。 這些發現和我們的研究支持審查小的更改的價值以及對研究和工具的需求,以幫助開發人員創建如此小的獨立代碼更改以進行審查。

7.2 實踐中的軟件工程研究

Google進行代碼審查的部分做法與軟件工程研究中提出的做法保持一致。 例如,微軟公司對代碼所有權的一項研究發現,應認真審查較小貢獻者所做的更改,以提高代碼質量。 我們發現,此概念是在Google上通過要求所有者批準而強制實施的。 同樣,以前的研究表明,通常有一個變更的審閱者將負責檢查代碼是否符合常規。 可讀性使此過程更加明確。 在下文中,我們將重點介紹使其成為“下一代代碼審查工具” 的CRITIQUE的功能。

審查者的建議。研究人員發現,對審稿代碼具有先驗知識的審稿人會提供更多有用的評論,因此工具可以為審稿人選擇提供支持。我們已經看到,審閱者推薦功能受工具支持,從而優先考慮那些最近編輯/審閱受審文件的人員。這證實了最近的研究,即頻繁的審稿人對模塊的發展做出了巨大的貢獻,應與頻繁的編輯者一并納入。在Google中,實際上,找到合適的審稿人似乎沒有問題,實際上,實施推薦的模型很簡單,因為它可以以編程方式識別所有者。這與其他用于標識審閱者的提議的工具相反,審閱者已經審閱了具有相似名稱的文件或考慮了諸如審閱中包含的評論數量之類的功能。 Google的工作重點是處理審稿人的工作量和暫時缺勤(與Microsoft的研究一致)。

靜態分析集成。對88位Mozilla開發人員進行的定性研究發現,靜態分析集成是代碼審查最常用的功能。 自動進行的分析使審閱者可以專注于更改的可理解性和可維護性,而不會因為瑣碎的評論(例如關于格式)而分心。 我們在Google的調查向我們展示了在代碼審閱工具中進行靜態分析集成的實際含義。CRITIQUE為分析作者集成了反饋渠道:審閱者可以選擇在分析生成的評論上單擊“請修復”,以表示作者應修復該問題,作者或審稿人都可以單擊“無用”以標記對審閱過程無用的分析結果。具有較高“無用”點擊率的分析儀已固定或禁用。我們發現,這種反饋循環對于維持開發人員對分析結果的信任至關重要。

協作審查之外的審查工具。最后,我們找到了有力的證據,表明CRITIQUE的使用超出了審查代碼。 變更作者使用CRITIQUE來檢查差異并瀏覽分析工具的結果。 在某些情況下,代碼審查是變更開發過程的一部分:一個審查者可能會發送未完成的變更,以便決定如何完成實施。此外,開發人員還使用CRITIQUE來檢查提交的更改的歷史,只要這些更改被批準即可。 這與Sutherland和Venolia設想的將代碼審查數據用于開發的有益用法相一致。 將來的工作可以調查代碼審查工具的這些意外的和潛在的有影響的非審查使用。

7.3 知識傳播

知識轉移是Rigby和Bird提出的主題。 為了衡量由于代碼審查而導致的知識轉移,他們從先驗工作的角度出發,通過測量變更,審查和兩個集合的不同文件數來衡量專業知識,以更改的文件數為依據 。他們發現開發人員通過代碼審查了解更多文件。

在Google,知識轉移是代碼審查教育動機的一部分。 我們試圖通過查看評論和編輯/審閱的文件來量化此效果。 隨著開發人員積累了在Google工作的經驗,他們對其更改發表的評論平均減少了(圖2)。在過去一年內開始工作的Google開發人員,每次更改的注釋通常多于兩倍。先前的工作發現,作者認為來自審閱者的注釋無用,而無用注釋的數目則隨著經驗的增加而減少。 我們假設評論的減少是由于審閱者在使用代碼庫建立譜系關系時需要詢問較少的問題的結果,并佐證了代碼審閱的教育方面可能隨著時間的流逝而得到回報的假說。此外,我們可以看到, 由Google的工程師編輯和審查的文件,以及這兩個集合的結合,隨著資歷的增加而增加(圖3),并且看到的文件總數明顯大于編輯的文件數。 在公司工作(以3個月為增量),然后計算他們已編輯和審閱的文件數。在以后的工作中,更好地了解審閱文件如何影響開發人員的流利性將是很有意思的。

圖2. 審查者的評論和開發者在Google的任職年限

圖3. 全職員工隨時間查看(編輯或審閱,或兩者都有)的不同文件的數量。

8.結論

我們的研究發現,代碼審查是Google開發工作流程的重要方面。擔任所有職務的開發人員都將其視為提供多種好處的環境,并且在此上下文中,開發人員可以相互學習代碼庫,維護團隊代碼庫的完整性以及搭建,建立和發展確保代碼庫可讀性和一致性的規范。開發人員報告說,他們對審查代碼的要求感到滿意。大部分更改很小,只有一名審閱者,除了提交授權外沒有其他評論。在一周中,有70%的更改在郵寄出去進行初審后不到24小時內就會提交。這些特征使代碼審查比其他采用類似過程的項目更輕便。此外,我們發現Google在其實踐中包含了一些研究思想,從而使當前研究趨勢的實踐意義顯而易見。

原文地址:https://dl.acm.org/doi/10.114...

閱讀 2.3k
639 聲望
936 粉絲
0 條評論
639 聲望
936 粉絲
宣傳欄
一本到在线是免费观看_亚洲2020天天堂在线观看_国产欧美亚洲精品第一页_最好看的2018中文字幕 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>