11個高效的同行代碼評審最佳實踐

11個高效的同行代碼評審最佳實踐作者:JasonCohen來源:IBM發(fā)布時間:2012-08-1113:40閱讀:549次原文鏈接全屏閱讀[收藏]摘要：這11項針對輕量級高效同行代碼評審最佳實踐被證明是有效的，它們建立在一個通過結(jié)合使用IBM?RationalTeamConcert?與SmartBearCodeCollaborator對Cisco系統(tǒng)的開發(fā)進行案例研究的基礎(chǔ)之上。它們可以幫助您確保評審既能夠改進您的代碼，又能利用好開發(fā)人員的時間。英文原文：11provenpracticesformoreeffective,efficientpeercodereviewSmartBearSoftware團隊?花費了數(shù)年時間去搜索已有的代碼評審研究成果，并從超過100家公司的6000多名程序員那里，收集了“實踐經(jīng)驗”。很顯然，人們在評審代碼時會發(fā)現(xiàn)一些錯誤（bug），但是這種評審工作通常會花費大量的時間，因此變得不太實際。我們通過數(shù)十年的經(jīng)驗使用獲得的信息，來創(chuàng)建輕量級代碼評審的概念。通過使用輕量級代碼評審技術(shù)，開發(fā)員只需要花費五分之一的時間就可以進行全面且規(guī)范的代碼評審工作了。我們還開發(fā)了最佳實踐的理論，以便部署實現(xiàn)評審的效率與價值。本文概括了以下的這些實踐。為了測試我們對代碼評審及輕量級評審的結(jié)論，我們對代碼評審進行了最大規(guī)模的研究工作。它涉及包含了2500個代碼評審案例，50個程序員，及Cisco系統(tǒng)上320萬行的代碼。在10個月的時間內(nèi)，研究追蹤了MeetingPlace產(chǎn)品團隊，該團隊擁有Bangalore，Budapest及SanJosé方面的成員。在研究開始時，我們要為這個團隊創(chuàng)建以下的規(guī)則：在簽入到團隊的版本控制軟件之前，所有的代碼都必須進行評審。SmartBear的CodeCollaborator?代碼評審軟件工具，應(yīng)該用于精化，組織和改進所有的代碼評審工作。代碼評審的全體會議是不允許的。評審過程會得到工具的支持。CodeCollaborator會自動收集工具，提供評審層次和總結(jié)層次的報告。根據(jù)我們的研究結(jié)果，總結(jié)了11項最佳實踐您應(yīng)該警惕，平等代碼評審（在該過程中，軟件發(fā)布以確保質(zhì)量之前，軟件開發(fā)員會相互評審代碼）會識別代碼中存在的錯誤（bug），鼓勵協(xié)作，并使代碼變得更有維護性。但是很明顯的一點是，有些代碼評審技術(shù)是低效低能的。評審過程中的一些會議會占用時間，并抑制活力。嚴格的流程會扼殺創(chuàng)造力，但是松散的流程又意味著沒人知道評審是否有效，甚至是否發(fā)生。而個人批評的社會效應(yīng)，又會損傷士氣。本文描述了考慮效率時的11項最佳實踐，科學研究和SmartBear領(lǐng)域內(nèi)的經(jīng)驗證明輕量級同行評審是高效的。使用這些技術(shù)，可以確保代碼評審能夠改進代碼—而不用占用開發(fā)員的時間。您可以使用最新的技術(shù)，在IBM?RationalTeamConcert?環(huán)境之中評審代碼。1.一次評審量要低于200–400行代碼關(guān)于Cisco案例研究在10個月的監(jiān)視工作之后，研究總結(jié)出了一個理論：如果適當操作的話，輕量級代碼評審工作與規(guī)范的評審工作同樣有效，但是前者的速度會更快（更省時）。與規(guī)范評審相比，輕量級代碼評審平均要少花6.5個小時，并發(fā)現(xiàn)更多的錯誤（bug）。除了確認這些理論，研究中還發(fā)現(xiàn)了一些新的規(guī)律，本文將這些規(guī)律都概括了出來。Cisco代碼評審研究顯示了為了得到優(yōu)化的效率，開發(fā)人員的評審量要低于一次200-400行代碼（LOC）。超過這個量，搜索缺陷的能力就會降低。以這個速度，您可以找到70-90%的缺陷。換句話說，如果存在10個缺陷，那么您可以找到其中的7到9個。圖1.當代碼行數(shù)量超過200時缺陷密度就會急劇下降，400以后缺陷密度幾乎為0圖1中的圖，描述了缺陷密度與評審代碼行數(shù)量之間的關(guān)系，支持該規(guī)則。缺陷密度就是每1000行代碼之中所發(fā)現(xiàn)的錯誤（bug）數(shù)。評審代碼行的數(shù)量超過200時，缺陷密度就會急劇地下降。在這種情況下，缺陷密度就是“評審有效性”的評價手段。如果兩個評審員評審相同的代碼，其中一個發(fā)現(xiàn)了更多的錯誤（bug），那么我們就會認為該評審員更有效率。圖1顯示了當我們將更多的代碼放到評審者面前時，她搜索缺陷效率的變化情況。這種結(jié)果很合理，因為她可能不會花費大量的時間去評審，這樣就會不可避免的使得效率沒有以前高。2.每小時低于300–500LOC檢查率的目標定義檢查率：我們能夠多快地評審代碼呢？通常以每小時kLOC（千代碼行）來評價。缺陷率：我們能夠多快地發(fā)現(xiàn)缺陷呢？通常以每小時缺陷數(shù)來評價。缺陷密度：給定量的代碼之中我們能夠發(fā)現(xiàn)多少的缺陷呢（而不是它們有多少）？通常以每kLOC中發(fā)現(xiàn)的缺陷數(shù)來評價。您要花點時間進行代碼評審。快速評審并不總是好的。我們的研究結(jié)果顯示檢查率低于“300-500LOC/小時”時，可以得到優(yōu)化的結(jié)果。根據(jù)所作的決定，評審者的檢查率有很大的變化，就算是相似的代碼開發(fā)者、評審者，文件和評審規(guī)模，也存在巨大的差異。為了找到優(yōu)化的檢查率，我們將缺陷密度與評審者檢查代碼的速度進行了比較。得到的結(jié)果再一次落在了我們的預料之中：如果在評審時您不花足夠的時間，那么您就不會發(fā)現(xiàn)太多的缺陷。如果評審者面臨大量代碼的壓力，那么他就不會每一行代碼投入相同的注意力。他不能研究同一位置處更改的所有版本。所以，多快算是太快呢？圖2顯示了答案：服務(wù)器端每小時超過400LOC的評審速度會降低效率。而每小時1000LOC的速度，您可能已經(jīng)退出了，以這樣的速度評審員可能根本都沒有細看代碼。圖2.評審量超過500行代碼時檢查效率就會下降了3.花足夠的時間進行適當緩慢的評審，但是不要超過60-90分鐘永遠不要對一個原型代碼評審超過60-90分鐘我們應(yīng)該討論，為了得到更好的結(jié)果，不應(yīng)該過快地評價。但是您也不應(yīng)該在一個位置花太多的時間。大約60分鐘后，評審者就會感到疲勞，于是就不會找到額外的缺陷了。這個結(jié)論得到了許多其他研究的支持。實際上，根據(jù)我們的常識，當人們從事注意力高度集中的活動時，性能狀態(tài)在60-90分鐘之后就會降低了?？紤]到人體方面的限制，評審者在性能降低之前，不能評審超過300~600行的代碼。但反過來說，評審代碼所花的時間不得低于五分鐘，就算代碼只有一行也是如此。通常來說，單行的代碼也會影響到整個的系統(tǒng)，所以花上五分鐘時間去檢查更改可能造成的結(jié)果是值得的。4.確定在評審開始之前代碼開發(fā)者已經(jīng)注釋源代碼了在評審開始之前代碼開發(fā)者可能就消除大多數(shù)的缺陷，這一點我們將會看到。如果我們需要開發(fā)人員雙倍地檢查他們的工作，那么評審可能更快地完成，而不用再去折中考慮代碼質(zhì)量的問題。就我們所知，這種特定的想法尚未得到研究，所以我們在Cisco研究期間對其進行了測試。圖3.“代碼開發(fā)者準備”對缺陷密度的震撼性效果“代碼開發(fā)者準備”說的是代碼開發(fā)者在評審之前要先注釋他們的源代碼。我們發(fā)明了這個術(shù)語，以描述研究中所評價的特定行為模式，大約15%的評審會阻止代碼開發(fā)者這樣做。注釋會指導評審者進行變更，顯示首先必須要查看的文件，并找到每一次代碼更改的原因。這些注釋不是代碼之中的評論，而只是給其他評審者看的評論。我們的理論就是，因為代碼開發(fā)者需要重新考慮，并解釋注釋過程中所發(fā)生的更改，所以代碼開發(fā)者需要在評審開始之前就找出許多缺陷，以讓評審變得更加有效。如此，評審過程將會產(chǎn)生低密度的缺陷，因為更少的錯誤（bug）剩余了。很明顯，與沒有代碼開發(fā)者準備的評審相比，代碼開發(fā)者準備之后的評審有更少的缺陷存在。我們還考慮過一個悲觀的理論，以解釋錯誤（bug）的低發(fā)現(xiàn)率。是不是當代碼開發(fā)者在作出一項評論時，評審者會有偏見，或者自鳴得意，這樣就不能盡可能多地發(fā)現(xiàn)錯誤（bug）了呢？我們隨機抽查了300個評審者進行研究，結(jié)果證實評審者在評審代碼時確實非常小心，更少的錯誤（bug）被發(fā)現(xiàn)了。5.為代碼評審創(chuàng)建可定量化的目標，并獲取制度，這樣您就可以改進流程了有了項目，您就該決定代碼評審過程的目標，以及怎樣評價效率問題了。當您在定義特定的目標時，您就能夠決定同行評審是否真的達到了您所需要的結(jié)果。最好從外部性的制度開始，例如“將支持訪問降低20%”或者“使開發(fā)引入的缺陷百分比減半”。這些信息使您能夠更好地看清，從外部視角來看，代碼能夠做些什么，您還需要一個可定量化的評價手段，而不是“修復更多錯誤（bug）”的模糊目標。但是，在外部制度顯示結(jié)果之前需要花上一段時間。例如，支持性訪問將不會得到影響，直到新的版本得到發(fā)布并交到客戶手中為止。所以查看內(nèi)部性流程工具，以得到發(fā)現(xiàn)多少缺陷，缺陷就是問題所在，以及開發(fā)人員在評審上所花時間的清晰結(jié)果。代碼評審的最常見內(nèi)部性制度是檢查率，缺陷率，以及缺陷密度。考慮一下只有自動化或者緊密控制的流程，才能給您帶來可重復的代碼；人類并不擅長記住啟動或者終止計時器。為了得到最好的結(jié)果，您要使用能夠自動收集代碼的代碼評審工具，這樣用于流程改進的關(guān)鍵代碼就是精確的了。為了改進和提高您的流程，您可以收集代碼并組合流程，以查看更改是如何影響結(jié)果的。很快，您就將會知道什么工作最適合您的團隊了。6.使用檢查表，因為它能極大地影響代碼開發(fā)者和評審者的結(jié)果使用檢測表對于評審員非常重要，如果代碼開發(fā)者忘記了某項任務(wù)，評審員也同樣可能忘記。我們極力推薦您使用檢查表，來確定您可能會忘記的事情，它對代碼開發(fā)者和評審者都有用。忽略是最難發(fā)現(xiàn)的缺陷；畢竟，評審不在那里的東西是很困難的一件事。檢查表是解決這個問題的最好方式，因為它會提醒評審者和代碼開發(fā)者花點時間去考慮一下可能被遺忘的事情。檢查表還會提醒代碼開發(fā)者和評審者確定所有的錯誤（bug）都得到了處理，軟件功能已經(jīng)通過了無效值測驗，而且已經(jīng)創(chuàng)建了單元測試。另外一個有用的概念就是個人檢查表。每個人一般都會犯15-20個錯誤（bug）。如果您注意到了一些典型的錯誤（bug），那么您就可以開發(fā)自己的個人檢查表（PersonalSoftwareProcess，SoftwareEngineeringInstitute，以及CapabilityMaturityModelIntegrated也都推薦該實踐方式）。評審者將會完成決定一般性錯誤（bug）的工作。您所應(yīng)該做的，就是擁有一個簡短的檢查列表，一般都是您容易遺忘的事情。一旦您開始在檢查列表中記錄自己的缺陷，那么您就會少犯錯了。規(guī)則將不斷出現(xiàn)在您的腦海中，然后您的錯誤（bug）率就會下降了。這種情況我們將會發(fā)現(xiàn)它反復出現(xiàn)。提示：如果您想要得到關(guān)于檢查列表的更多具體信息，那么您可以得到本文代碼開發(fā)者所寫書籍的免費拷貝，這本書為BestKeptSecretsofPeerCodeReview，網(wǎng)址為www.CodeReviewB。7.確認缺陷得到了修復是的，這種“最佳實踐”看起來好像是沒有腦子的。如果您遇到了評審代碼以找到缺陷的所有問題，那么修復它們就變得順理成章了！現(xiàn)在許多評審代碼的團隊沒有一種好的辦法，去追蹤評審期間找到的缺陷，并確保評審完成之前錯誤（bug）確實得到了修復。確認電子郵件之中的結(jié)果，或者實時評審是非常困難的。記住這些錯誤（bug）通常不是在RationalTeamConcert日志中輸入的，因為在代碼發(fā)布給QA之前就發(fā)現(xiàn)了這些錯誤（bug）。所以，什么是代碼在貼上“全部解決”標志之前確認缺陷的好辦法呢？我們建議使用好的協(xié)作性評審軟件，與RationalTeamConcert相集成，以追蹤評審之中所發(fā)現(xiàn)的缺陷。有了正確的工具，評審員就可以記錄錯誤（bug），并在必要時與代碼開發(fā)者進行討論了。然后代碼開發(fā)者會修復問題，并通知評審者，而評審者必須確認每個問題都得到了解決。工具應(yīng)該追蹤評審期間所發(fā)現(xiàn)的問題，并確保直到所有的錯誤（bug）被評審者修復才完成評審（或者作為稍后解決的單獨工作項追蹤）。工作項只有在評審完成時才能通過。如果您真面臨著搜索錯誤（bug）的煩惱，那么請確認您已經(jīng)將它們?nèi)堪惭b了！既然您已經(jīng)學會了代碼評審流程的最佳實踐方式，那么我們接下來將會討論一些社會效應(yīng)，以及怎樣管理它們以獲得最佳的結(jié)果。8.培養(yǎng)良好的代碼評審文化氛圍，在這樣的氛圍中可以積極地評審缺陷與其他我們能看到的大多數(shù)技術(shù)相比，代碼評審對于真實團隊構(gòu)建能夠發(fā)揮更大的作用，但是只是在管理人員能夠以一種積極的，向上的，有技巧的方式進行交流時，這種優(yōu)勢才能發(fā)揮出來。將缺陷看做是不好的事物很容易（畢竟，它們是代碼之中的錯誤(bug)），但是形成不好的缺陷檢查態(tài)度，則會毀掉整個團隊的努力，更不要說它會破壞錯誤（bug）檢查過程了。軟件代碼評審的要點在于，盡可能多的消除缺陷，不管是誰“導致”了錯誤（bug）。管理人員必須建立缺陷是積極的這樣的觀點。畢竟，每一個缺陷的存在，都是改進代碼的潛在機會，而錯誤（bug）評審過程的目的，就在于使代碼盡可能地完美。每一個被發(fā)現(xiàn)并解決的缺陷，都是客戶以后不會看到的缺陷，也是QA人員不必花費時間去解決的問題。團隊需要維持這樣一種態(tài)度，就是發(fā)現(xiàn)缺陷，就意味著代碼開發(fā)者和評審者作為一個團隊去改進產(chǎn)品的質(zhì)量成功了。而不是“代碼開發(fā)者產(chǎn)生了一個缺陷，而評審者負責去發(fā)現(xiàn)它”。它更像是結(jié)對編程的一種有效形式。評審員要向所有的開發(fā)者展示收集壞習慣，學習新技巧，并展開功能的機會。開發(fā)人員可以從他們的錯誤（bug）中學習，但是只是在他們警惕錯誤（bug）時才會這樣。如果開發(fā)人員害怕發(fā)現(xiàn)錯誤（bug），那么積極的結(jié)果就會消失。如果您是一名初級開發(fā)人員，或者是一個團隊的新成員，那么其他人發(fā)現(xiàn)缺陷時，就意味著您強有力的隊友在幫助您成長為一個合格的開發(fā)員。這就比您單槍匹馬地編程，沒有具體的反饋時，要更快地進步。為了維持檢查缺陷是積極的這樣一種理念，管理人員必須要承諾缺陷密度不會進入到性能報告之中。公開作出這種承諾是很有效的。這樣開發(fā)員就會知道他們要怎樣做，并抗議公開破壞這條規(guī)則的管理人員。管理人員絕不應(yīng)該將錯誤（bug）代碼作為消極性能評審的基礎(chǔ)。他們必須謹慎對待，并對批評造成的挫折感及消極反應(yīng)保持敏感，并要一直提醒團隊發(fā)現(xiàn)錯誤（bug）是一件很好的事情。9.警惕老大哥效應(yīng)（BigBrotherEffect）作為一個開發(fā)人員，您可以自動假設(shè)“老大哥正看著您呢”是真的，如果評審制度是由評審支持工具自動評價的，更是這樣的。您是否花費了很長的時間去評審一下更改？您的同行從您的代碼中是否發(fā)現(xiàn)了很多錯誤（bug）？這將如何影響您下一步的性能評價？評估報表不應(yīng)用來對付開發(fā)人員，尤其是在面對結(jié)對評審員時。這一做法會嚴重破壞道德觀。制度對于流程評價來說非常重要，這反過來，又為流程改進提供了一個基礎(chǔ)。但是制度也可以被用來做壞事。如果開發(fā)人員相信制度是用來對付他們的，那么他們不光是對流程有敵意，而且他們的注意力可能轉(zhuǎn)到改變制度，而不是編寫更好的代碼，和變得更有效率上。管理人員可以做很多事情，來解決這個問題。首先也是最重要的，他們必須要警惕這一點，并且必須確定代碼開發(fā)者沒有面臨很多的壓力，而“老大哥”問題必須每次都得到詳細的檢查。制度應(yīng)該用來評價流程的效率，或者流程更改的效果。記住，通常來說，最困難的代碼是由最有經(jīng)驗的開發(fā)人員處理的。這些代碼，反過來，最有可能出問題，因此最難檢查，也有可能發(fā)現(xiàn)最多的缺陷。因此，大量的缺陷很有可能是由復雜性，以及代碼的分塊性造成的，而不是代碼開發(fā)者的能力造成的。如果制度確實能夠幫助一個管理人員去發(fā)現(xiàn)一個問題，那么將某人踢出局可能會產(chǎn)生更多的問題。我們推薦管理人員在解決相關(guān)問題時，要將一個小組當做整體來對待。所以最好不要召開專門的會議，因為開發(fā)人員在解決特定的問題可能會有壓力。相反，您可以通過一個每周狀態(tài)會議，或者正常的程序來解決問題。管理人員必須不斷地維持這樣一個年頭，即搜索缺陷是好的事情，而不是糟糕的，缺陷密度與開發(fā)員的能力并不是掛鉤的。記住對一個團隊來說，缺陷，尤其是團隊成員所引入缺陷的數(shù)量不應(yīng)該被回避，也不應(yīng)該用作能力的評價參數(shù)。10.評審一部分的代碼，就算您不能全部完成，以從自我效能感（EgoEffect）中獲益想象一下您自己坐在編譯器的前面，任務(wù)是需要修復一個小小的錯誤（bug）。但是您知道只要您說出了“我完成了”，您的同行—或者更糟，您的老板—就要檢查您的工作了。這會改變您的開發(fā)個性嗎？所以在您工作時，一般是在您聲明代碼評審完成之前，就會更加的謹慎了。如此您立即就會成為一個更好的開發(fā)人員了，因為在您背后別人議論您時就會說，“他的員工非常謹慎，他真是一個不錯的開發(fā)人員”；而不是“他犯了大量愚蠢的錯誤（bug）。當他說工作完成時，實際上還差著遠呢”。自我效能感（EgoEffect）會促使開發(fā)人員編寫更好的代碼，因為他們知道其他人將會查看自己編寫的代碼及作品。沒有人想被其他人認為自己經(jīng)常犯初級的錯誤（bug）。EgoEffect促使開發(fā)人員在向其他人交付作品時更加謹慎地進行評審。EgoEffect的一個良好特征，是不管評審者要對所有的代碼變更負責，還是僅僅執(zhí)行“點檢查”，就像隨機性的藥物測試一樣，都能正常地發(fā)揮作用。如果您的代碼有三分之一的幾率被評審者抽中進行評審，那么它仍然足以刺激評審者謹慎工作。如果您只有十分之一的概率被抽中檢查，那么可能您就不會如此勤奮了。您知道您會說，“哈，我很少犯錯”。評審20%~33%的代碼時，從EgoEffect中獲得花費時間方面的收益可能最大，評審20%的代碼肯定要比不評審強很多。11.采用輕量級，工具支持的代碼評審代碼評審一般有些主要的類型和無數(shù)的變數(shù)，而指南卻能適用它們中的任何一個。但是，為了完全優(yōu)化團隊花在評審之上的時間，我們要使用工具支持的輕量級評審過程來得到最優(yōu)的結(jié)果。搜索缺席時，它是有效的，實用的。規(guī)范，或者重量級的檢查已經(jīng)流行了30年。它已經(jīng)不是評審代碼的有效形式了。重量級檢查平均花費的時間是每200行代碼9個小時。盡管它很有效，但是嚴格的過程需要三到六個參與者，并進行一系列繁瑣的會議以討論具體的細節(jié)。不幸的是，盡管需要繁瑣的過程，但是大多數(shù)的公司沒有條件將編程人員集成起來，進行長時間的會議。最近的幾年，許多開發(fā)公司已經(jīng)完全放棄了會議安排，紙質(zhì)代碼閱讀，以及繁瑣的作品收集工作，轉(zhuǎn)而采用新型輕量級過程，以從規(guī)范的會議及老式重量級過程的重壓中解放起來。我們使用在Cisco中的案例研究，來確定輕量級技術(shù)與規(guī)范過程比較的特點。結(jié)果顯示輕量級代碼評審所需要的時間只是規(guī)范評審的五分之一（甚至更少），而且前者能夠發(fā)現(xiàn)更多的錯誤（bug）。盡管輕量級代碼評審擁有很多的方法，例如實時評審和電子郵件評審，但是最有效的評審方法還是使用協(xié)作性的軟件工具來促進評審，這些軟件工具例如SmartBear的CodeCollaborator（見于圖4）。圖4的大圖圖4.Cisco研究中所使用到的輕量級代碼評審工具，CodeCollaboratorCodeCollaborator是與IBM?RationalTeamConcert工作流程相集成的唯一代碼評審工具。它將源代碼評審與聊天形式的協(xié)作集成起來，從而使開發(fā)人員從聯(lián)系注釋與私人代碼行的繁瑣活動中解放了出來。當程序員向工作項添加更改項進行評審時，在CodeCollaborator中將會自動創(chuàng)建評審，并分配適當?shù)呐鷾收?。團隊成員可以直接注釋代碼，與代碼開發(fā)者聊天，并就每一個問題進行協(xié)作，追蹤錯誤（bug）并修復缺陷。整個過程不需要會議，打印，或者安排日程。有了基于RationalTeamConcert與CodeCollaborator的輕量級評審過程，團隊就可以進行更有效的評審，并實現(xiàn)代碼評審的有利點。CodeCollaborator獲得了"ReadyforIBMRationa