簡(jiǎn)介： 這 11 項(xiàng)針對(duì)輕量級(jí)高效同行代碼評(píng)審***實(shí)踐被證明是有效的，它們建立在一個(gè)通過(guò)結(jié)合使用 IBM® Rational Team Concert™ 與 SmartBear CodeCollaborator 對(duì) Cisco 系統(tǒng)的開(kāi)發(fā)進(jìn)行案例研究的基礎(chǔ)之上。它們可以幫助您確保評(píng)審既能夠改進(jìn)您的代碼，又能利用好開(kāi)發(fā)人員的時(shí)間。

SmartBear Software 團(tuán)隊(duì)® 花費(fèi)了數(shù)年時(shí)間去搜索已有的代碼評(píng)審研究成果，并從來(lái)自超過(guò) 100 家公司的 6000 多名程序員那里，收集了“實(shí)踐經(jīng)驗(yàn)”。很顯然，人們?cè)谠u(píng)審代碼時(shí)會(huì)發(fā)現(xiàn)一些錯(cuò)誤（bug），但是這種評(píng)審工作通常會(huì)花費(fèi)大量的時(shí)間，因此變得不太實(shí)際。我們通過(guò)數(shù)十年的經(jīng)驗(yàn)使用獲得的信息，來(lái)創(chuàng)建輕量級(jí)代碼評(píng)審的概念。通過(guò)使用輕量級(jí)代碼評(píng)審技術(shù)，開(kāi)發(fā)員只需要花費(fèi)五分之一的時(shí)間就可以進(jìn)行全面且規(guī)范的代碼評(píng)審工作了。我們還開(kāi)發(fā)了***實(shí)踐的理論，以便部署實(shí)現(xiàn)評(píng)審的效率與價(jià)值。本文概括了以下的這些實(shí)踐。

為了測(cè)試我們對(duì)代碼評(píng)審及輕量級(jí)評(píng)審的結(jié)論，我們對(duì)代碼評(píng)審進(jìn)行了***規(guī)模的研究工作。它涉及包含了2500 個(gè)代碼評(píng)審案例，50 個(gè)程序員，及 Cisco 系統(tǒng)上320 萬(wàn)行的代碼。在 10 個(gè)月的時(shí)間內(nèi)，研究追蹤了 MeetingPlace 產(chǎn)品團(tuán)隊(duì)，該團(tuán)隊(duì)擁有 Bangalore，Budapest 及 San José 方面的成員。

在研究開(kāi)始時(shí)，我們要為這個(gè)團(tuán)隊(duì)創(chuàng)建以下的規(guī)則：

在檢入到團(tuán)隊(duì)的版本控制軟件之前，所有的代碼都必須進(jìn)行評(píng)審。

SmartBear 的 CodeCollaborator® 代碼評(píng)審軟件工具，應(yīng)該用于精化，組織和改進(jìn)所有的代碼評(píng)審工作。

代碼評(píng)審的全體會(huì)議是不支持的。

評(píng)審過(guò)程會(huì)得到工具的支持。

CodeCollaborator 會(huì)自動(dòng)收集工具，提供評(píng)審層次和總結(jié)層次的報(bào)告。

根據(jù)我們的研究結(jié)果，總結(jié)了 11 項(xiàng)***實(shí)踐

您應(yīng)該警惕，平等代碼評(píng)審（在該過(guò)程中，軟件發(fā)布以確保質(zhì)量之前，軟件開(kāi)發(fā)員會(huì)相互評(píng)審代碼）會(huì)識(shí)別代碼中存在的錯(cuò)誤（bug），鼓勵(lì)協(xié)作，并使代碼變得更有維護(hù)性。

但是很明顯的一點(diǎn)是，有些代碼評(píng)審技術(shù)是低效低能的。評(píng)審過(guò)程中的一些會(huì)議會(huì)占用時(shí)間，并抑制活力。嚴(yán)格的流程會(huì)扼殺創(chuàng)造力，但是松散的流程又意味著沒(méi)人知道評(píng)審是否有效，甚至是否發(fā)生。而個(gè)人批評(píng)的社會(huì)效應(yīng)，又會(huì)損傷士氣。

本文描述了考慮效率時(shí)的 11 項(xiàng)***實(shí)踐，科學(xué)研究和 SmartBear 領(lǐng)域內(nèi)的經(jīng)驗(yàn)證明輕量級(jí)同行評(píng)審是高效的。使用這些技術(shù)，可以確保代碼評(píng)審能夠改進(jìn)代碼 – 而不用占用開(kāi)發(fā)員的時(shí)間。您可以使用最近的技術(shù)，來(lái)在 IBM® Rational Team Concert® 環(huán)境之中評(píng)審代碼。

1. 一次評(píng)審量要低于 200–400 行代碼

Cisco 代碼評(píng)審研究（見(jiàn)于工具欄）顯示了為了得到優(yōu)化的效率，開(kāi)發(fā)員的評(píng)審量要低于一次 200-400 行代碼（LOC）。超過(guò)這個(gè)量，搜索缺陷的能力就會(huì)降低。以這個(gè)速度，您可以找到 70-90% 的缺陷。換句話說(shuō)，如果存在 10 個(gè)缺陷，那么您可以找到其中的 7 到 9 個(gè)。

關(guān)于 Cisco 案例研究

在 10 個(gè)月的監(jiān)視工作之后，研究總結(jié)出了一個(gè)理論：如果適當(dāng)操作的話，輕量級(jí)代碼評(píng)審工作與規(guī)范的評(píng)審工作同樣有效，但是前者的速度會(huì)更快（更省時(shí)）。與規(guī)范評(píng)審相比，輕量級(jí)代碼評(píng)審平均要少花 6.5 個(gè)小時(shí)，并發(fā)現(xiàn)更多的錯(cuò)誤（bug）。

除了確認(rèn)這些理論，研究中還發(fā)現(xiàn)了一些新的規(guī)律，本文將這些規(guī)律都概括了出來(lái)。

圖 1 中的圖，描述了缺陷密度與評(píng)審代碼行數(shù)量之間的關(guān)系，支持該規(guī)則。缺陷密度 就是每 1000 行代碼之中所發(fā)現(xiàn)的錯(cuò)誤（bug）數(shù)。評(píng)審代碼行的數(shù)量超過(guò) 200 時(shí)，缺陷密度就會(huì)急劇地下降。

在這種情況下，缺陷密度就是“評(píng)審有效性”的評(píng)價(jià)手段。如果兩個(gè)評(píng)審員評(píng)審相同的代碼，其中一個(gè)發(fā)現(xiàn)了更多的錯(cuò)誤（bug），那么我們就會(huì)認(rèn)為該評(píng)審員更有效率。圖 1 顯示了當(dāng)我們將更多的代碼放到評(píng)審者面前時(shí)，她搜索缺陷效率的變化情況。這種結(jié)果很合理，因?yàn)樗赡懿粫?huì)花費(fèi)大量的時(shí)間去評(píng)審，這樣就會(huì)不可避免的使得效率沒(méi)有以前高。

圖 1. 當(dāng)代碼行數(shù)量超過(guò) 200 時(shí)缺陷密度就會(huì)急劇下降，400 以后缺陷密度幾乎為 0

2. 每小時(shí)低于 300–500 LOC 檢查率的目標(biāo)

定義

檢查率： 我們能夠多快地評(píng)審代碼呢？通常以每小時(shí) kLOC（千代碼行）來(lái)評(píng)價(jià)。

缺陷率： 我們能夠多快地發(fā)現(xiàn)缺陷呢？通常以每小時(shí)缺陷數(shù)來(lái)評(píng)價(jià)。

缺陷密度： 給定量的代碼之中我們能夠發(fā)現(xiàn)多少的缺陷呢（而不是它們有多少）？通常以每 kLOC 中發(fā)現(xiàn)的缺陷數(shù)來(lái)評(píng)價(jià)。

您要花點(diǎn)時(shí)間進(jìn)行代碼評(píng)審。快速評(píng)審并不總是好的。我們的研究結(jié)果顯示檢查率低于“300-500 LOC/小時(shí)”時(shí)，可以得到優(yōu)化的結(jié)果。根據(jù)所作的決定，評(píng)審者的檢查率有很大的變化，就算是相似的代碼開(kāi)發(fā)者、評(píng)審者，文件和評(píng)審規(guī)模，也存在巨大的差異。

為了找到優(yōu)化的檢查率，我們將 缺陷密度 與評(píng)審者檢查代碼的 速度 進(jìn)行了比較。得到的結(jié)果再一次落在了我們的預(yù)料之中：如果在評(píng)審您不花足夠的時(shí)間，那么您就不會(huì)發(fā)現(xiàn)太多的缺陷。如果評(píng)審者面臨大量代碼的壓力，那么他就不會(huì)每一行代碼投入相同的注意力。他不能研究同一位置處更改的所有版本。

所以，多快算是太快呢？圖 2 顯示了答案：服務(wù)器端每小時(shí)超過(guò) 400 LOC 的評(píng)審速度會(huì)降低效率。而每小時(shí) 1000 LOC 的速度，您可能已經(jīng)推出了，以這樣的速度評(píng)審員可能根本都沒(méi)有細(xì)看代碼。

圖 2. 評(píng)審量超過(guò) 500 行代碼時(shí)檢查效率就會(huì)下降了

3. 花足夠的時(shí)間進(jìn)行適當(dāng)緩慢的評(píng)審，但是不要超過(guò) 60-90 分鐘

永遠(yuǎn)不要對(duì)一個(gè)原型代碼評(píng)審超過(guò) 60-90 分鐘

我們應(yīng)該討論，為了得到更好的結(jié)果，不應(yīng)該過(guò)快地評(píng)價(jià)。但是您也不應(yīng)該在一個(gè)位置花太多的時(shí)間。大約 60 分鐘后，評(píng)審者就會(huì)感到疲勞，于是就不會(huì)找到額外的缺陷了。這個(gè)結(jié)論得到了許多其他研究的支持。實(shí)際上，根據(jù)我們的常識(shí)，當(dāng)人們從事注意力高度集中的活動(dòng)時(shí)，性能狀態(tài)在 60-90 分鐘之后就會(huì)降低了?？紤]到人體方面的限制，評(píng)審者在性能降低之前，不能評(píng)審超過(guò) 300–600 行的代碼。

但反過(guò)來(lái)說(shuō)，評(píng)審代碼所花的時(shí)間不得低于五分鐘，就算代碼只有一行也是如此。通常來(lái)說(shuō)，單行的代碼也會(huì)影響到整個(gè)的系統(tǒng)，所以花上五分鐘時(shí)間去檢查更改可能造成的結(jié)果是值得的。

4. 確定在評(píng)審開(kāi)始之前代碼開(kāi)發(fā)者已經(jīng)注釋源代碼了

在評(píng)審開(kāi)始之前代碼開(kāi)發(fā)者可能就消除大多數(shù)的缺陷，這一點(diǎn)我們將會(huì)看到。如果我們需要開(kāi)發(fā)員雙倍地檢查他們的工作，那么評(píng)審可能更快地完成，而不用再去折中考慮代碼質(zhì)量的問(wèn)題。就我們所知，這種特定的想法尚未得到研究，所以我們?cè)?Cisco 研究期間對(duì)其進(jìn)行了測(cè)試。

圖 3. 代碼開(kāi)發(fā)者準(zhǔn)備對(duì)缺陷密度的震撼性效果

代碼開(kāi)發(fā)者準(zhǔn)備 說(shuō)的是代碼開(kāi)發(fā)者在評(píng)審之前要先注釋他們的源代碼。我們發(fā)明了這個(gè)術(shù)語(yǔ)，以描述研究中所評(píng)價(jià)的特定行為模式，大約 15% 的評(píng)審會(huì)阻止代碼開(kāi)發(fā)者這樣做。注釋會(huì)指導(dǎo)評(píng)審者進(jìn)行變更，顯示首先必須要查看的文件，并找到每一次代碼更改的原因。這些注釋不是代碼之中的評(píng)論，而只是給其他評(píng)審者看的評(píng)論。

我們的理論就是，因?yàn)榇a開(kāi)發(fā)者需要重新考慮，并解釋注釋過(guò)程中所發(fā)生的更改，所以代碼開(kāi)發(fā)者需要在評(píng)審開(kāi)始之前就找出許多缺陷，以讓評(píng)審變得更加有效。如此，評(píng)審過(guò)程將會(huì)產(chǎn)生低密度的缺陷，因?yàn)楦俚腻e(cuò)誤（bug）剩余了。很明顯，與沒(méi)有代碼開(kāi)發(fā)者準(zhǔn)備的評(píng)審相比，代碼開(kāi)發(fā)者準(zhǔn)備之后的評(píng)審有更少的缺陷存在。

我們還考慮過(guò)一個(gè)悲觀的理論，以解釋錯(cuò)誤（bug）的低發(fā)現(xiàn)率。是不是當(dāng)代碼開(kāi)發(fā)者在作出一項(xiàng)評(píng)論時(shí)，評(píng)審者會(huì)有偏見(jiàn)，或者自鳴得意，這樣就不能盡可能多地發(fā)現(xiàn)錯(cuò)誤（bug）了呢？我們隨機(jī)抽查了 300 個(gè)評(píng)審者進(jìn)行研究，結(jié)果證實(shí)評(píng)審者在評(píng)審代碼時(shí)確實(shí)非常小心，更少的錯(cuò)誤（bug）被發(fā)現(xiàn)了。

5. 為代碼評(píng)審創(chuàng)建可定量化的目標(biāo)，并獲取制度，這樣您就可以改進(jìn)流程了

有了項(xiàng)目，您就該決定代碼評(píng)審過(guò)程的目標(biāo)，以及怎樣評(píng)價(jià)效率問(wèn)題了。當(dāng)您在定義特定的目標(biāo)時(shí)，您就能夠決定同行評(píng)審是否真的達(dá)到了您所需要的結(jié)果。

***從外部性的制度開(kāi)始，例如“將支持訪問(wèn)降低 20%”或者“使開(kāi)發(fā)引入的缺陷百分比減半”。這些信息使您能夠更好地看清，從外部視角來(lái)看，代碼能夠做些什么，您還需要一個(gè)可定量化的評(píng)價(jià)手段，而不是“修復(fù)更多錯(cuò)誤（bug）”的模糊目標(biāo)。

但是，在外部制度顯示結(jié)果之前需要花上一段時(shí)間。例如，支持性訪問(wèn)將不會(huì)得到影響，直到新的版本得到發(fā)布并交到客戶(hù)手中為止。所以查看內(nèi)部性流程工具，以得到發(fā)現(xiàn)多少缺陷，缺陷就是問(wèn)題所在，以及開(kāi)發(fā)員在評(píng)審上所花時(shí)間的清晰結(jié)果。代碼評(píng)審的最常見(jiàn)內(nèi)部性制度是 檢查率 ，缺陷率，以及 缺陷密度。

考慮一下只有自動(dòng)化或者緊密控制的流程，才能給您帶來(lái)可重復(fù)的代碼；人類(lèi)并不擅長(zhǎng)記住啟動(dòng)或者終止計(jì)時(shí)器。為了得到***的結(jié)果，您要使用能夠 自動(dòng) 收集代碼的代碼評(píng)審工具，這樣用于流程改進(jìn)的關(guān)鍵代碼就是精確的了。

為了改進(jìn)和提高您的流程，您可以收集代碼并組合流程，以查看更改是如何影響結(jié)果的。很快，您就將會(huì)知道什么工作最適合您的團(tuán)隊(duì)了。

6. 使用檢查表，因?yàn)樗軜O大地影響代碼開(kāi)發(fā)者和評(píng)審者的結(jié)果

使用檢測(cè)表對(duì)于評(píng)審員非常重要，如果代碼開(kāi)發(fā)者忘記了某項(xiàng)任務(wù)，評(píng)審員也同樣可能忘記。

我們極力推薦您使用檢查表，來(lái)確定您可能會(huì)忘記的事情，它對(duì)代碼開(kāi)發(fā)者和評(píng)審者都有用。忽略是最難發(fā)現(xiàn)的缺陷；畢竟，評(píng)審不在那里的東西是很困難的一件事。檢查表是解決這個(gè)問(wèn)題的***方式，因?yàn)樗鼤?huì)提醒評(píng)審者和代碼開(kāi)發(fā)者花點(diǎn)時(shí)間去考慮一下可能被遺忘的事情。檢查表還會(huì)提醒代碼開(kāi)發(fā)者和評(píng)審者確定所有的錯(cuò)誤（bug）都得到了處理，軟件功能已經(jīng)通過(guò)了無(wú)效值測(cè)驗(yàn)，而且已經(jīng)創(chuàng)建了單元測(cè)試。

另外一個(gè)有用的概念就是 個(gè)人檢查表 。每個(gè)人一般都會(huì)犯 15-20 個(gè)錯(cuò)誤（bug）。如果您注意到了一些典型的錯(cuò)誤（bug），那么您就可以開(kāi)發(fā)自己的個(gè)人檢查表（Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推薦該實(shí)踐方式）。評(píng)審者將會(huì)完成決定一般性錯(cuò)誤（bug）的工作。您所應(yīng)該做的，就是擁有一個(gè)簡(jiǎn)短的檢查列表，一般都是您容易遺忘的事情。

一旦您開(kāi)始在檢查列表中記錄自己的缺陷，那么您就會(huì)少犯錯(cuò)了。規(guī)則將不斷出現(xiàn)在您的腦海中，然后您的錯(cuò)誤（bug）率就會(huì)下降了。這種情況我們將會(huì)發(fā)現(xiàn)它反復(fù)出現(xiàn)。
提示：
如果您想要得到關(guān)于檢查列表的更多具體信息，那么您可以得到本文代碼開(kāi)發(fā)者所寫(xiě)書(shū)籍的免費(fèi)拷貝，這本書(shū)為 Best Kept Secrets of Peer Code Review，網(wǎng)址為 www.CodeReviewBook.com。

#p#

7. 確認(rèn)缺陷得到了修復(fù)

是的，這種“***實(shí)踐”看起來(lái)好像是沒(méi)有腦子的。如果您遇到了評(píng)審代碼以找到缺陷的所有問(wèn)題，那么修復(fù)它們就變得順理成章了！現(xiàn)在許多評(píng)審代碼的團(tuán)隊(duì)沒(méi)有一種好的辦法，去追蹤評(píng)審期間找到的缺陷，并確保評(píng)審?fù)瓿芍板e(cuò)誤（bug）確實(shí)得到了修復(fù)。確認(rèn)電子郵件之中的結(jié)果，或者實(shí)時(shí)評(píng)審是非常困難的。

記住這些錯(cuò)誤（bug）通常不是在 Rational Team Concert 日志中輸入的，因?yàn)樵诖a發(fā)布給 QA 之前就發(fā)現(xiàn)了這些錯(cuò)誤（bug）。所以，什么是代碼在貼上“全部解決”標(biāo)志之前確認(rèn)缺陷的好辦法呢？我們建議使用好的協(xié)作性評(píng)審軟件，與 Rational Team Concert 相集成，以追蹤評(píng)審之中所發(fā)現(xiàn)的缺陷。有了正確的工具，評(píng)審員就可以記錄錯(cuò)誤（bug），并在必要時(shí)與代碼開(kāi)發(fā)者進(jìn)行討論了。然后代碼開(kāi)發(fā)者會(huì)修復(fù)問(wèn)題，并通知評(píng)審者，而評(píng)審者必須確認(rèn)每個(gè)問(wèn)題都得到了解決。工具應(yīng)該追蹤評(píng)審期間所發(fā)現(xiàn)的問(wèn)題，并確保直到所有的錯(cuò)誤（bug）被評(píng)審者 修復(fù) 才完成評(píng)審（或者作為稍后解決的單獨(dú)工作項(xiàng)追蹤）。工作項(xiàng)只有在評(píng)審?fù)瓿蓵r(shí)才能通過(guò)。

如果您真面臨著搜索錯(cuò)誤（bug）的煩惱，那么請(qǐng)確認(rèn)您已經(jīng)將它們?nèi)堪惭b了！

既然您已經(jīng)學(xué)會(huì)了代碼評(píng)審 流程 的***實(shí)踐方式，那么我們接下來(lái)將會(huì)討論一些社會(huì)效應(yīng)，以及怎樣管理它們以獲得***的結(jié)果。

8. 培養(yǎng)良好的代碼評(píng)審文化氛圍，在這樣的氛圍中可以積極地評(píng)審缺陷

與其他我們能看到的大多數(shù)技術(shù)相比，代碼評(píng)審對(duì)于真實(shí)團(tuán)隊(duì)構(gòu)建能夠發(fā)揮更大的作用，但是只是在管理人員能夠以一種積極的，向上的，有技巧的方式進(jìn)行交流時(shí)，這種優(yōu)勢(shì)才能發(fā)揮出來(lái)。將缺陷看做是不好的事物很容易（畢竟，它們是代碼之中的錯(cuò)誤（bug）），但是形成不好的缺陷檢查態(tài)度，則會(huì)毀掉整個(gè)團(tuán)隊(duì)的努力，更不要說(shuō)它會(huì)破壞錯(cuò)誤（bug）檢查過(guò)程了。

軟件代碼評(píng)審的要點(diǎn)在于，盡可能多的消除缺陷，不管是誰(shuí)“導(dǎo)致”了錯(cuò)誤（bug）。

管理人員必須建立缺陷是積極的這樣的觀點(diǎn)。畢竟，每一個(gè)缺陷的存在，都是改進(jìn)代碼的潛在機(jī)會(huì)，而錯(cuò)誤（bug）評(píng)審過(guò)程的目的，就在于使代碼盡可能地***。每一個(gè)被發(fā)現(xiàn)并解決的缺陷，都是客戶(hù)以后不會(huì)看到的缺陷，也是 QA 人員不必花費(fèi)時(shí)間去解決的問(wèn)題。

團(tuán)隊(duì)需要維持這樣一種態(tài)度，就是發(fā)現(xiàn)缺陷，就意味著代碼開(kāi)發(fā)者和評(píng)審者 作為一個(gè)團(tuán)隊(duì) 去改進(jìn)產(chǎn)品的質(zhì)量成功了。而不是“代碼開(kāi)發(fā)者產(chǎn)生了一個(gè)缺陷，而評(píng)審者負(fù)責(zé)去發(fā)現(xiàn)它”。它更像是配對(duì)編程的一種有效形式。

評(píng)審員要向所有的開(kāi)發(fā)者展示收集壞習(xí)慣，學(xué)習(xí)新技巧，并展開(kāi)功能的機(jī)會(huì)。開(kāi)發(fā)員可以從他們的錯(cuò)誤（bug）中學(xué)習(xí)，但是只是在他們警惕錯(cuò)誤（bug）時(shí)才會(huì)這樣。如果開(kāi)發(fā)員害怕發(fā)現(xiàn)錯(cuò)誤（bug），那么積極的結(jié)果就會(huì)消失。

如果您是一名初級(jí)開(kāi)發(fā)員，或者是一個(gè)團(tuán)隊(duì)的新成員，那么其他人發(fā)現(xiàn)缺陷時(shí)，就意味著您強(qiáng)有力的隊(duì)友在幫助您成長(zhǎng)為一個(gè)合格的開(kāi)發(fā)員。這就比您單槍匹馬地編程，沒(méi)有具體的反饋時(shí)，要更快地進(jìn)步。

為了維持檢查缺陷是積極的這樣一種理念，管理人員必須要承諾缺陷密度不會(huì)進(jìn)入到性能報(bào)告之中。公開(kāi)作出這種承諾是很有效的。這樣開(kāi)發(fā)員就會(huì)知道他們要怎樣做，并抗議公開(kāi)破壞這條規(guī)則的管理人員。

管理人員絕不應(yīng)該將錯(cuò)誤（bug）代碼作為消極性能評(píng)審的基礎(chǔ)。他們必須謹(jǐn)慎對(duì)待，并對(duì)批評(píng)造成的挫折感及消極反應(yīng)保持敏感，并要一直提醒團(tuán)隊(duì)發(fā)現(xiàn)錯(cuò)誤（bug）是一件很好的事情。

9. 警惕老大哥效應(yīng)（Big Brother Effect）

作為一個(gè)開(kāi)發(fā)員，您可以自動(dòng)假設(shè)“老大哥正看著您呢”是真的，如果評(píng)審制度是由評(píng)審支持工具自動(dòng)評(píng)價(jià)的，更是這樣的。您是否花費(fèi)了很長(zhǎng)的時(shí)間去評(píng)審一下更改？您的同行從您的代碼中是否發(fā)現(xiàn)了很多錯(cuò)誤（bug）？這將如何影響您下一步的性能評(píng)價(jià)？

評(píng)估報(bào)表不應(yīng)用來(lái)對(duì)付開(kāi)發(fā)人員，尤其是在面對(duì)結(jié)對(duì)評(píng)審員時(shí)。這一做法會(huì)嚴(yán)重破壞道德觀。

制度對(duì)于流程評(píng)價(jià)來(lái)說(shuō)非常重要，這反過(guò)來(lái)，又為流程改進(jìn)提供了一個(gè)基礎(chǔ)。但是制度也可以被用來(lái)做壞事。如果開(kāi)發(fā)員相信制度是用來(lái)對(duì)付他們的，那么他們不光是對(duì)流程有敵意，而且他們的注意力可能轉(zhuǎn)到改變制度，而不是編寫(xiě)更好的代碼，和變得更有效率上。

管理員可以做很多事情，來(lái)解決這個(gè)問(wèn)題。首先也是最重要的，他們必須要警惕這一點(diǎn)，并且必須確定代碼開(kāi)發(fā)者沒(méi)有面臨很多的壓力，而“老大哥”問(wèn)題必須每次都得到詳細(xì)的檢查。

制度應(yīng)該用來(lái)評(píng)價(jià)流程的效率，或者流程更改的效果。記住，通常來(lái)說(shuō)，最困難的代碼是由最有經(jīng)驗(yàn)的開(kāi)發(fā)員處理的。這些代碼，反過(guò)來(lái)，最有可能出問(wèn)題，因此最難檢查，也有可能發(fā)現(xiàn)最多的缺陷。因此，大量的缺陷很有可能是由復(fù)雜性，以及代碼的分塊性造成的，而不是代碼開(kāi)發(fā)者的能力造成的。

如果制度確實(shí)能夠幫助一個(gè)管理員去發(fā)現(xiàn)一個(gè)問(wèn)題，那么將某人踢出局可能會(huì)產(chǎn)生更多的問(wèn)題。我們推薦管理員在解決相關(guān)問(wèn)題時(shí)，要將一個(gè)小組當(dāng)做整體來(lái)對(duì)待。所以***不要召開(kāi)專(zhuān)門(mén)的會(huì)議，因?yàn)殚_(kāi)發(fā)員在解決特定的問(wèn)題可能會(huì)有壓力。相反，您可以通過(guò)一個(gè)每周狀態(tài)會(huì)議，或者正常的程序來(lái)解決問(wèn)題。

管理員必須不斷地維持這樣一個(gè)年頭，即搜索缺陷是好的事情，而不是糟糕的，缺陷密度與開(kāi)發(fā)員的能力并不是掛鉤的。記住對(duì)一個(gè)團(tuán)隊(duì)來(lái)說(shuō)，缺陷，尤其是團(tuán)隊(duì)成員所引入缺陷的數(shù)量不應(yīng)該被回避，也不應(yīng)該用作能力的評(píng)價(jià)參數(shù)。

10. 評(píng)審一部分的代碼，就算您不能全部完成，以從自我效能感（Ego Effect）中獲益

想象一下您自己坐在編譯器的前面，任務(wù)是需要修復(fù)一個(gè)小小的錯(cuò)誤（bug）。但是您知道只要您說(shuō)出了“我完成了”，您的同行 — 或者更糟，您的老板 — 就要檢查您的工作了。這會(huì)改變您的開(kāi)發(fā)個(gè)性嗎？所以在您工作時(shí)，一般是在您聲明代碼評(píng)審?fù)瓿芍埃蜁?huì)更加的謹(jǐn)慎了。如此您立即就會(huì)成為一個(gè)更好的開(kāi)發(fā)員了，因?yàn)樵谀澈髣e人議論您時(shí)就會(huì)說(shuō)，“他的員工非常謹(jǐn)慎，他真是一個(gè)不錯(cuò)的開(kāi)發(fā)員”；而不是“他犯了大量愚蠢的錯(cuò)誤（bug）。當(dāng)他說(shuō)工作完成時(shí)，實(shí)際上還差著遠(yuǎn)呢”。

自我效能感（Ego Effect）會(huì)促使開(kāi)發(fā)員編寫(xiě)更好的代碼，因?yàn)樗麄冎榔渌藢?huì)查看自己編寫(xiě)的代碼及作品。沒(méi)有人想被其他人認(rèn)為自己經(jīng)常犯初級(jí)的錯(cuò)誤（bug）。Ego Effect 促使開(kāi)發(fā)員在向其他人交付作品時(shí)更加謹(jǐn)慎地進(jìn)行評(píng)審。

Ego Effect 的一個(gè)良好特征，是不管評(píng)審者要對(duì)所有的代碼變更負(fù)責(zé)，還是僅僅執(zhí)行“點(diǎn)檢查”，就像隨機(jī)性的藥物測(cè)試一樣，都能正常地發(fā)揮作用。如果您的代碼有三分之一的幾率被評(píng)審者抽中進(jìn)行評(píng)審，那么它仍然足以刺激評(píng)審者謹(jǐn)慎工作。如果您只有十分之一的概率被抽中檢查，那么可能您就不會(huì)如此勤奮了。您知道您會(huì)說(shuō)，“哈，我很少犯錯(cuò)”。

評(píng)審 20–33% 的代碼時(shí)，從 Ego Effect 中獲得花費(fèi)時(shí)間方面的收益可能***，評(píng)審 20% 的代碼肯定要比不評(píng)審強(qiáng)很多。

11. 采用輕量級(jí)，工具支持的代碼評(píng)審

代碼評(píng)審一般有些主要的類(lèi)型和無(wú)數(shù)的變數(shù)，而指南卻能適用它們中的任何一個(gè)。但是，為了完全優(yōu)化團(tuán)隊(duì)花在評(píng)審之上的時(shí)間，我們要使用工具支持的輕量級(jí)評(píng)審過(guò)程來(lái)得到***的結(jié)果。搜索缺席時(shí)，它是有效的，實(shí)用的。

規(guī)范，或者 重量級(jí)的 檢查已經(jīng)流行了 30 年。它已經(jīng)不是評(píng)審代碼的有效形式了。重量級(jí)檢查平均花費(fèi)的時(shí)間是每 200 行代碼 9 個(gè)小時(shí)。盡管它很有效，但是嚴(yán)格的過(guò)程需要三到六個(gè)參與者，并進(jìn)行一系列繁瑣的會(huì)議以討論具體的細(xì)節(jié)。不幸的是，盡管需要繁瑣的過(guò)程，但是大多數(shù)的公司沒(méi)有條件將編程人員集成起來(lái),進(jìn)行長(zhǎng)時(shí)間的會(huì)議。最近的幾年，許多開(kāi)發(fā)公司已經(jīng)完全放棄了會(huì)議安排，紙質(zhì)代碼閱讀，以及繁瑣的作品收集工作，轉(zhuǎn)而采用新型 輕量級(jí) 過(guò)程，以從規(guī)范的會(huì)議及老式重量級(jí)過(guò)程的重壓中解放起來(lái)。

我們使用在 Cisco 中的案例研究，來(lái)確定輕量級(jí)技術(shù)與規(guī)范過(guò)程比較的特點(diǎn)。結(jié)果顯示輕量級(jí)代碼評(píng)審所需要的時(shí)間只是規(guī)范評(píng)審的五分之一（甚至更少），而且前者能夠發(fā)現(xiàn)更多的錯(cuò)誤（bug）。

盡管輕量級(jí)代碼評(píng)審擁有很多的方法，例如實(shí)時(shí)評(píng)審和電子郵件評(píng)審，但是最有效的評(píng)審方法還是使用協(xié)作性的軟件工具來(lái)促進(jìn)評(píng)審，這些軟件工具例如 SmartBear 的 CodeCollaborator（見(jiàn)于圖 4）。

圖 4. Cisco 研究中所使用到的輕量級(jí)代碼評(píng)審工具，CodeCollaborator

CodeCollaborator 是與 IBM® Rational Team Concert 工作流程相集成的唯一代碼評(píng)審工具。它將源代碼評(píng)審與聊天形式的協(xié)作集成起來(lái)，從而使開(kāi)發(fā)員從聯(lián)系注釋與私人代碼行的繁瑣活動(dòng)中解放了出來(lái)。當(dāng)程序員向工作項(xiàng)添加更改項(xiàng)進(jìn)行評(píng)審時(shí)，在 CodeCollaborator 中將會(huì)自動(dòng)創(chuàng)建評(píng)審，并分配適當(dāng)?shù)呐鷾?zhǔn)者。團(tuán)隊(duì)成員可以直接注釋代碼，與代碼開(kāi)發(fā)者聊天，并就每一個(gè)問(wèn)題進(jìn)行協(xié)作，追蹤錯(cuò)誤（bug）并修復(fù)缺陷。整個(gè)過(guò)程不需要會(huì)議，打印，或者安排日程。

有了基于 Rational Team Concert 與 CodeCollaborator 的輕量級(jí)評(píng)審過(guò)程，團(tuán)隊(duì)就可以進(jìn)行更有效的評(píng)審，并實(shí)現(xiàn)代碼評(píng)審的有利點(diǎn)。

CodeCollaborator 獲得了 “Ready for IBM Rational Software” 針對(duì) Rational Team Concert V2 和 V3 的認(rèn)證，以及針對(duì) IBM® Rational® ClearCase® 和 IBM® Rational® Synergy® 的認(rèn)證。

到現(xiàn)在為止，您已經(jīng)被經(jīng)實(shí)踐證明有效的經(jīng)驗(yàn)從頭到尾武裝起來(lái)了，以確保從過(guò)程和社會(huì)的角度來(lái)看，團(tuán)隊(duì)在代碼評(píng)審過(guò)程之中能夠節(jié)省大量的時(shí)間。當(dāng)然，您必須確實(shí) 完成了 代碼評(píng)審，以實(shí)現(xiàn)這些便利。對(duì) 100% 的代碼使用評(píng)審的規(guī)范方法（有人對(duì)這個(gè)百分比存在異議，簡(jiǎn)單來(lái)說(shuō)是不現(xiàn)實(shí)的。集成到 Rational Team Concert 環(huán)境之中的工具支持輕量級(jí)代碼評(píng)審，提供了***大的功能，因?yàn)樗峁┝艘粋€(gè)有效的方法去搜索缺陷，而且不會(huì)涉及到開(kāi)發(fā)員頭痛的一些問(wèn)題。有了正確的工具和這些實(shí)踐方式，您的團(tuán)隊(duì)就可以對(duì)所有的代碼進(jìn)行同行評(píng)審，并在軟件達(dá)到 QA 階段之前就找到成本極高的錯(cuò)誤（bug），這樣您的客戶(hù)每次都能夠得到***品質(zhì)的產(chǎn)品了。

為了方便您查看，下面總結(jié)了在一個(gè)簡(jiǎn)單列表中最容易保持的 11 項(xiàng)實(shí)踐方式：

1、一次評(píng)審少于 200–400 行的代碼。

2、目標(biāo)為每小時(shí)低于 300–500 LOC 的檢查速率。

3、花足夠的時(shí)間進(jìn)行正確緩慢的評(píng)審，但是不要超過(guò) 60–90 分鐘。

4、確定代碼開(kāi)發(fā)者在評(píng)審開(kāi)始之前就已經(jīng)注釋了源代碼。

5、為代碼評(píng)審和獲取制度建立可定量化的目標(biāo)，這樣您才能改進(jìn)流程。

6、使用檢查列表，因?yàn)樗梢詷O大地改進(jìn)代碼開(kāi)發(fā)者和評(píng)審者的作品。

7、確認(rèn)缺陷確實(shí)得到修復(fù)了。

8、培養(yǎng)良好的代碼評(píng)審文化氛圍，在這樣的氛圍中搜索缺陷被看做是積極的活動(dòng)。

9、警惕“老大”效應(yīng)。

10、最少評(píng)審一部分代碼，就是您不能評(píng)審全部的代碼，以從 Ego Effect 中受益。

11、采用輕量級(jí)，能用工具支持的代碼評(píng)審。