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