本文譯自Google最新開放的code review指南：How to do a code review

原文地址：https://google.github.io/eng-practices/review/reviewer/

該文檔一共分為如下六篇：

Code Review的標(biāo)準(zhǔn)

Code Review關(guān)注點(diǎn)

CL閱讀指南

Code Review 的速度

如何編寫Code Review 評語

處理pushback

一底洗、 Code review的標(biāo)準(zhǔn)

Code review 的主要目的是確保Google代碼庫的整體代碼運(yùn)行狀況隨著時間的推移而得到改善碰镜。Code review的所有工具和流程都是為此而設(shè)計的。

為了實(shí)現(xiàn)這一目標(biāo)吠各，必須綜合考慮許多因素劲妙，并做出取舍和平衡和泌。

首先荧呐，開發(fā)人員必須能夠在任務(wù)上取得進(jìn)展读拆。如果你從不向代碼庫提交改進(jìn)后的代碼擅憔，那么代碼庫就永遠(yuǎn)不會得到改進(jìn)。另外檐晕，如果一個reviewer使任何更改都很難進(jìn)行暑诸，那么開發(fā)人員就不愿意在將來進(jìn)行改進(jìn)。

另一方面辟灰，reviewer有責(zé)任確保每個CL(Change Log)具有這樣的質(zhì)量屠列，即隨著時間的推移，其代碼庫的整體代碼健康狀況不會降低伞矩。這可能很棘手笛洛，因?yàn)榇a庫通常會隨著時間的推移而降低代碼運(yùn)行狀況，特別是當(dāng)團(tuán)隊的交付受到嚴(yán)重的時間限制乃坤，并且他們覺得必須采取捷徑才能實(shí)現(xiàn)目標(biāo)時苛让。

此外沟蔑，reviewer對他們正在審核的代碼擁有所有權(quán)和責(zé)任。他們希望確保代碼庫保持一致狱杰，可維護(hù)以及“code review中要注意的內(nèi)容”中提到的所有其他內(nèi)容瘦材。

因此，我們將以下規(guī)則作為我們在code review中期望的標(biāo)準(zhǔn)：

一般來說仿畸，如果一個 CL并不完美食棕，但是它肯定會提高當(dāng)前系統(tǒng)的代碼整體健康度，那reviewer就應(yīng)該讓它通過错沽。

這是所有code review指南中的首要原則簿晓。

當(dāng)然，這是有局限性的千埃。例如憔儿，如果一個CL添加了一個reviewer不希望在其系統(tǒng)中使用的功能，即使代碼設(shè)計得很好放可，reviewer也可以拒絕批準(zhǔn)該CL谒臼。

這里的一個關(guān)鍵點(diǎn)是，沒有“完美”的代碼耀里，只有更好的代碼蜈缤。Reviewer不應(yīng)該要求開發(fā)人員對CL的每一個微小的部分進(jìn)行打磨。相反冯挎，reviewer應(yīng)該在項(xiàng)目的進(jìn)展和reviewer的改進(jìn)建議兩者之間做好權(quán)衡底哥。Reviewer不應(yīng)該追求完美，而應(yīng)該追求持續(xù)的改進(jìn)织堂。作為一個整體叠艳，提高系統(tǒng)可維護(hù)性、可讀性和可理解性的CL不應(yīng)該因?yàn)樗皇恰巴昝赖摹倍舆t幾天或幾周通過審批易阳。

如果有些東西可以做得更好附较，reviewer 應(yīng)該隨時留下評論。但是如果該評論所建議的改進(jìn)不是很重要潦俺，可以在前面加上“Nit:”這樣的前綴拒课，讓作者知道這種改進(jìn)只是一種錦上添花的效果，作者可以選擇忽略事示。

注意：本文檔中沒有任何內(nèi)容推薦合入會明顯惡化系統(tǒng)的整體代碼健康狀況的CL早像。只有在緊急情況下你才會那樣做。

指導(dǎo)思想

Code review的一個重要功能是教授開發(fā)人員關(guān)于語言肖爵、框架或一般軟件設(shè)計原則的新知識卢鹦。留下幫助開發(fā)人員學(xué)習(xí)新東西的評論總是好的。隨著時間的推移劝堪，共享知識是改善系統(tǒng)代碼健康狀況的一部分冀自。請記住揉稚，如果您的評論純粹是教育性的，但對于滿足本文檔中描述的標(biāo)準(zhǔn)并不是至關(guān)重要的熬粗，那么在它前面加上“Nit:”搀玖，或者以其他方式表明并不強(qiáng)制作者在本CL中解決它。

原則

技術(shù)事實(shí)和數(shù)據(jù)優(yōu)先于意見和個人偏好驻呐。

在風(fēng)格問題上灌诅，以風(fēng)格指南為準(zhǔn)則。任何風(fēng)格指南中沒有規(guī)定的純樣式點(diǎn)(空格等)都是個人偏好的問題含末。這些點(diǎn)原則上應(yīng)該與現(xiàn)有的風(fēng)格保持一致猜拾。但是如果這些點(diǎn)現(xiàn)在還沒有形成一定的風(fēng)格，那reviewer應(yīng)該接受作者的風(fēng)格答渔。

軟件設(shè)計的各個方面幾乎從來不是純粹的風(fēng)格問題关带，也不只是個人偏好侥涵。它們是建立在基本原則的基礎(chǔ)上的沼撕，應(yīng)該在這些原則的基礎(chǔ)上加以衡量，而不僅僅是只考慮個人意見芜飘。有時务豺，如果作者能夠證明(通過數(shù)據(jù)或基于可靠的工程原理)幾種方法是同樣有效的，那么reviewer應(yīng)該接受作者的偏好嗦明。否則笼沥，reviewer的選擇取決于軟件設(shè)計的標(biāo)準(zhǔn)原則。

如果沒有其他規(guī)則適用娶牌，那么reviewer可能會要求作者與當(dāng)前代碼庫中的內(nèi)容保持一致奔浅，只要這不會惡化系統(tǒng)的整體代碼健康狀況。

解決沖突

在對代碼評審的任何沖突中诗良，開發(fā)人員和reviewer應(yīng)該始終根據(jù)本文檔的內(nèi)容以及“CL Author 's Guide“和“Reviewer Guide”中的其他文檔汹桦，嘗試達(dá)成一致意見。

當(dāng)達(dá)成一致意見變得特別困難時鉴裹，在reviewer和作者之間進(jìn)行面對面的會議或VC(譯者注：不知道是什么的縮寫)將會有所幫助舞骆，而不是僅僅試圖通過code revier評論來解決沖突。(不過径荔，如果您這樣做了督禽，請確保將討論結(jié)果記錄在CL的評論中，以供將來的讀者參考总处。)

如果這不能解決問題狈惫，最常見的解決方法就是升級。升級路徑通常是更廣泛的團(tuán)隊討論鹦马，讓TL參與進(jìn)來胧谈，請求代碼維護(hù)人員作出決策玖院，或者請求Eng經(jīng)理提供幫助。不要因?yàn)樽髡吆蛯徃迦瞬荒苓_(dá)成一致意見而讓CL無所事事第岖。

二难菌、 Code review關(guān)注點(diǎn)

注意：在考慮這些要點(diǎn)時，請務(wù)必同時參考“Code review的標(biāo)準(zhǔn)”蔑滓。

設(shè)計

Code review 評論最重要的內(nèi)容是CL的總體設(shè)計郊酒。CL中不同代碼段之間的交互有意義嗎?這個更改屬于您的代碼庫，還是屬于庫?它與系統(tǒng)的其他部分集成得好嗎?現(xiàn)在是添加此功能的恰當(dāng)時機(jī)嗎?

功能

這個CL是否達(dá)到了開發(fā)人員的目的?開發(fā)人員的意圖對這段代碼的用戶有好處嗎?“用戶”通常是終端用戶(當(dāng)他們受到更改的影響時)和開發(fā)人員(將來必須“使用”這些代碼)键袱。

大多數(shù)情況下燎窘，我們希望開發(fā)人員能夠很好地測試CLs，以便在進(jìn)行codereview時代碼能夠正確地工作蹄咖。然而褐健，作為reviewer，您仍然應(yīng)該考慮一些邊界情況澜汤，尋找并發(fā)性問題蚜迅，嘗試像用戶一樣思考問題，并確保不會看到僅通過閱讀代碼就能發(fā)現(xiàn)的錯誤俊抵。

如果您愿意谁不，您可以對CL進(jìn)行驗(yàn)證—檢查CL行為最重要的時間是當(dāng)它具有面向用戶的影響時檐什，例如UI更改锅纺。當(dāng)您僅僅閱讀代碼時，很難理解一些更改將如何影響用戶票堵。對于這樣的更改谎替，如果不方便在CL中進(jìn)行修補(bǔ)并親自嘗試偷溺，您可以讓開發(fā)人員提供功能的演示。

在代碼評審過程中考慮功能的另一個特別重要的時刻是钱贯，在CL中是否存在某種并發(fā)編程挫掏，這理論上可能會導(dǎo)致死鎖或競爭條件。僅通過運(yùn)行代碼很難發(fā)現(xiàn)這類問題喷舀，通常需要有人(開發(fā)人員和review)仔細(xì)考慮這些問題砍濒，以確保沒有引入問題。(注意硫麻，這也是一個不使用可能存在競爭條件或死鎖的并發(fā)模型的好理由——這會使code review或理解代碼變得非常復(fù)雜爸邢。)

復(fù)雜性

CL比它應(yīng)該的復(fù)雜嗎?在cl的每一層檢查這個—單個行是不是太復(fù)雜了?函數(shù)是否過于復(fù)雜?類太復(fù)雜了嗎?“太復(fù)雜”通常意味著“代碼讀者不能很快理解”。這也意味著“當(dāng)開發(fā)人員試圖調(diào)用或修改這段代碼時拿愧，他們很可能會引入bug杠河。”

一種特殊類型的復(fù)雜性是過度設(shè)計，開發(fā)人員使代碼比需要的更通用券敌，或者增加了系統(tǒng)目前不需要的功能唾戚。reviewer應(yīng)該特別警惕過度設(shè)計。鼓勵開發(fā)人員解決他們知道現(xiàn)在需要解決的問題待诅，而不是解決開發(fā)人員推測將來可能需要解決的問題叹坦。未來的問題應(yīng)該在它到來后解決，你可以看到它在物理宇宙中的實(shí)際形狀和需求卑雁。

測試

根據(jù)更改要求進(jìn)行單元測試募书、集成測試或端到端測試。一般來說测蹲，測試應(yīng)該添加到與生產(chǎn)代碼相同的CL中莹捡，除非CL正在處理緊急情況。

確保CL中的測試是正確的扣甲、合理的和有用的篮赢。測試本身不進(jìn)行測試，而且我們很少為我們的測試編寫測試—人類必須確保測試是有效的琉挖。

當(dāng)代碼有問題時启泣，測試會真的失敗嗎?如果下面的代碼發(fā)生變化，它們會開始產(chǎn)生假陽性嗎?每個測試都做出簡單而有用的斷言嗎?測試是否在不同的測試方法之間適當(dāng)?shù)胤珠_?

請記住粹排，測試也是必須維護(hù)的代碼种远。不要僅僅因?yàn)闇y試不是主分支的一部分就接受測試中的復(fù)雜性涩澡。

命名

開發(fā)人員是否為所有東西都選擇了好名字?一個好的名字應(yīng)該足夠長顽耳，從而可以充分地表達(dá)條目是什么或做了什么，并且不會長到讓人難以閱讀妙同。

注釋

開發(fā)人員是否用可理解的英語編寫了清晰的注釋?所有的評論都是必要的嗎?通常射富，注釋在解釋某些代碼為什么存在時很有用，而不應(yīng)該解釋某些代碼在做什么粥帚。如果代碼不夠清晰胰耗，無法達(dá)到自解釋，那么應(yīng)該簡化代碼芒涡。也有一些例外(例如柴灯，解釋正則表達(dá)式和復(fù)雜算法在做什么通常幫助很大)，但大多數(shù)注釋是針對代碼本身不可能包含的信息费尽，比如決策背后的推理赠群。

查看CL之前的評論也會很有幫助。也許現(xiàn)在有一個可以刪除的待辦事項(xiàng)旱幼，一個建議不要做這個更改的評論查描，等等。

注意，注釋不同于類冬三、模塊或函數(shù)的文檔匀油，這些文檔應(yīng)該表示代碼的用途、應(yīng)該如何使用以及使用時的行為勾笆。

風(fēng)格

我們?yōu)镚oogle提供所有主要語言的風(fēng)格指南敌蚜，甚至包括大多數(shù)小眾語言。確保CL遵循適當(dāng)?shù)臉邮街改稀?/p>

如果你想改進(jìn)樣式指南中沒有涉及的一些樣式點(diǎn)窝爪，請在評論前加上“Nit：”钝侠，讓開發(fā)人員知道你認(rèn)為這會改善代碼，但不是強(qiáng)制性的酸舍。不要僅根據(jù)個人風(fēng)格偏好阻止提交CL帅韧。

CL的作者不應(yīng)將大量樣式更改和代碼更改放在一起提交。它使得很難看到CL中的代碼更改啃勉，使合并和回滾更復(fù)雜忽舟，并導(dǎo)致其他問題。例如淮阐，如果作者想要重新格式化整個文件叮阅，讓他們只將重新格式化為一個CL，然后再發(fā)送另一個CL及其功能更改泣特。

文檔

如果CL更改了用戶構(gòu)建浩姥、測試、交互或發(fā)布代碼的方式状您，請檢查它是否還更新了相關(guān)文檔勒叠，包括READMEs、g3doc頁面和任何生成的參考文檔膏孟。如果CL刪除或棄用代碼眯分，請考慮是否也應(yīng)該刪除文檔。如果缺少文檔柒桑，就去問作者要弊决。

每一行

查看分配給您的每一行代碼。有些東西魁淳，比如數(shù)據(jù)文件飘诗、生成的代碼或大型數(shù)據(jù)結(jié)構(gòu)，您有時可以大致瀏覽一下界逛，但是由人編寫的類昆稿、函數(shù)或代碼塊不能粗略的瀏覽，并假定其中的內(nèi)容是正確的仇奶。顯然貌嫡，有些代碼需要比其他代碼檢查的更仔細(xì)—這是您必須做出的判斷—但是您至少應(yīng)該確保您理解所有代碼在做什么比驻。

如果這段代碼您閱讀起來比較費(fèi)勁，并且會減慢評審的速度岛抄，那么您應(yīng)該讓開發(fā)人員知道這一點(diǎn)别惦，并在您嘗試評審之前等待他們澄清它。在谷歌夫椭，我們雇傭優(yōu)秀的軟件工程師掸掸，你就是其中之一。如果您不能理解代碼蹭秋，其他開發(fā)人員也很可能無法理解扰付。因此，當(dāng)您要求開發(fā)人員澄清這些代碼時仁讨，您也在幫助未來的開發(fā)人員理解這些代碼羽莺。

如果您理解所review的代碼，但是您覺得不能勝任這次review洞豁，那么請確保針對這個CL有一個合格的review盐固，特別是對于復(fù)雜的問題，比如安全性丈挟、并發(fā)性刁卜、可訪問性、國際化等等曙咽。

上下文

在廣泛的上下文中查看CL通常是有幫助的蛔趴。一般地，code review工具只會顯示正在更改的部分周圍的幾行代碼例朱。有時您必須查看整個文件孝情，以確保更改實(shí)際上是有意義的。例如茉继，您可能只看到添加了四行咧叭，但是當(dāng)您查看整個文件時，您會看到這四行位于一個50行方法中烁竭，現(xiàn)在確實(shí)需要將其分解為更小的方法。

在整個系統(tǒng)的上下文中考慮CL也很有用吉挣。這個CL是提高了系統(tǒng)的代碼健康度派撕，還是使整個系統(tǒng)更復(fù)雜、測試更少等等?不要接受降低系統(tǒng)代碼健康度的CLs睬魂。大多數(shù)系統(tǒng)都是通過許多累積起來的小更改而變得復(fù)雜的终吼，因此，即使是防止在新更改中引入很小的復(fù)雜性也是很重要的氯哮。

處理CL中好的方面

如果您在CL中看到一些不錯的東西际跪，請告訴開發(fā)人員，特別是當(dāng)他們以一種很好的方式處理您的一條評論的改進(jìn)建議。Code review通常只關(guān)注錯誤姆打，但是它們也應(yīng)該為好的實(shí)踐提供鼓勵和贊賞良姆。有時候，在指導(dǎo)方面幔戏，告訴開發(fā)人員他們做對了什么比告訴他們他們做錯了什么更有價值玛追。

總結(jié)

在code review過程中你應(yīng)確保:

代碼設(shè)計得很好。

該功能對代碼的用戶（開發(fā)人員以及系統(tǒng)的用戶）有益闲延。

任何UI更改都是合理的痊剖，看起來也不錯。

任何并發(fā)編程都是安全的垒玲。

代碼并不比它需要的復(fù)雜陆馁。

開發(fā)人員沒有實(shí)現(xiàn)他們將來可能需要但不知道現(xiàn)在是否需要的東西。

代碼有適當(dāng)?shù)膯卧獪y試合愈。

單元測試是精心設(shè)計過的氮惯。

開發(fā)人員在代碼中的所有命名都是清晰的。

注釋清晰有用想暗，主要解釋為什么而不是解釋是什么妇汗。

代碼被合適地文檔化了(通常在g3doc中)。

代碼符合我們的樣式指南说莫。

確保檢查您被要求檢查的每一行代碼杨箭，查看上下文，確保您正在改進(jìn)代碼的健康狀況储狭，并贊揚(yáng)開發(fā)人員做的好的地方互婿。

三、 CL閱讀指南

摘要

既然您知道“Code review關(guān)注點(diǎn)”辽狈，那么管理跨多個文件的codereview的最有效方法是什么?

這種變化有意義嗎? CL(change log)的描述清晰明了嗎?

首先看看CL中最重要的部分慈参。CL的整體設(shè)計好嗎?

按照適當(dāng)?shù)捻樞虿榭碈L的其余部分。

第一步:從全局的視角看下CL

看看CL的描述刮萌，以及CL大概做了什么驮配。CL涉及的變更有意義嗎?如果這個變更一開始就不應(yīng)該發(fā)生，請立即回復(fù)并解釋為什么不應(yīng)該發(fā)生變更着茸。當(dāng)您拒絕這樣的變更時壮锻，最好也向開發(fā)人員建議他們應(yīng)該做什么。

例如涮阔，你可以說“看起來你在這方面做得不錯猜绣，謝謝!”不過，我們實(shí)際上準(zhǔn)備刪除你在修改的FooWidget系統(tǒng)敬特，所以我們現(xiàn)在不想對它做任何新的修改掰邢。你不如來重構(gòu)我們的新BarWidget類?”

注意牺陶，review不僅要在拒絕了當(dāng)前的CL時提供一個替代的建議，而且很有禮貌的拒絕辣之。這種禮貌是很重要的掰伸，因?yàn)槲覀兿胍憩F(xiàn)出即使我們意見不一致，我們作為開發(fā)人員也彼此尊重召烂。

如果您發(fā)現(xiàn)出現(xiàn)多個你不希望進(jìn)行更改的CLs碱工，那么您應(yīng)該重新考慮一下團(tuán)隊的開發(fā)流程或外部貢獻(xiàn)者發(fā)布的流程，以便在他們編寫CLs之前跟你有更多的溝通奏夫。最好在人們完成大量工作之前就說“不”怕篷，這些工作現(xiàn)在必須扔掉或徹底重寫。

第二步：檢查CL的主要部分

找出這個CL的“主要”部分酗昼，CL的主要部分一般是一個或者幾個文件廊谓。通常，只有一個文件具有最多的邏輯更改麻削，它是CL的主要部分蒸痹。首先看看這些主要部分。這有助于為CL的所有較小部分提供上下文呛哟，并且通常這會加速代碼評審叠荠。如果CL太大，您無法確定哪些部分是主要部分扫责，請詢問開發(fā)人員應(yīng)該首先查看什么榛鼎，或者讓他們將CL分割成多個CLs。

如果您看到CL的這一部分存在一些主要的設(shè)計問題鳖孤，您應(yīng)該立即給出反饋者娱，即使您現(xiàn)在沒有時間來檢查CL的其余部分。事實(shí)上苏揣，檢查CL的其余部分可能是浪費(fèi)時間黄鳍，因?yàn)槿绻O(shè)計問題足夠嚴(yán)重，那么許多其他正在檢查的代碼后面可能會刪掉或者重構(gòu)平匈，不管怎樣都無關(guān)緊要框沟。

如果主要設(shè)計有缺陷，立即給出反饋非常重要吐葱，有兩個主要原因：

開發(fā)人員通常會提交一個CL街望，然后在等待評審時立即基于該CL開始新的工作。如果您正在檢查的CL中存在主要的設(shè)計問題弟跑，那么他們還必須重新編寫后面的CL。您應(yīng)該在它們在有問題的設(shè)計上做過多額外工作之前阻止它們防症。

大的設(shè)計變更比小的變更需要更長的時間孟辑。開發(fā)人員的任務(wù)幾乎都有截止日期;為了在代碼庫中保持高質(zhì)量代碼的同時在這些截止日期前完成任務(wù)哎甲，開發(fā)人員需要盡快開始對CL主要問題進(jìn)行修改。

第三步：以適當(dāng)?shù)捻樞虿榭碈L的其余部分

一旦你確認(rèn)整個CL沒有重大的設(shè)計問題饲嗽，試著找出一個邏輯序列來查看這些文件炭玫，同時確保你不會漏看任何文件。通常在查看主要文件之后貌虾，最簡單的方法是按照代碼審查工具向您提供的順序?yàn)g覽每個文件吞加。有時在閱讀主代碼之前先閱讀測試也很有幫助，因?yàn)檫@樣你就可以了解CL做了什么尽狠。

四衔憨、 Code review 的速度

為什么code review 要快？

在谷歌中袄膏，我們針對開發(fā)團(tuán)隊共同開發(fā)產(chǎn)品的速度進(jìn)行優(yōu)化践图，而不是針對單個開發(fā)人員編寫代碼的速度進(jìn)行優(yōu)化。個人發(fā)展的速度很重要沉馆，但是沒有整個團(tuán)隊的速度重要码党。

當(dāng)code review很慢時，會發(fā)生以下幾件事：

整個團(tuán)隊的速度降低了斥黑。如果一個人對評審的反應(yīng)不是很快揖盘，他雖然在這期間做了一些其他的工作，但是锌奴，由于每個CL都要等待一次又一次的評審兽狭，團(tuán)隊其他成員的新特性和bug修復(fù)會延遲幾天、幾周或幾個月缨叫。

開發(fā)人員開始抗議code review過程椭符。如果reviewer每隔幾天才回復(fù)一次，但每次都要求對CL進(jìn)行重大更改耻姥，這對開發(fā)人員來說可能是令人沮喪和困難的销钝。通常，這表現(xiàn)為對reviewer的“嚴(yán)格”的抱怨琐簇。如果reviewer請求相同的實(shí)質(zhì)性更改(這些更改確實(shí)改善了代碼的健康狀況)蒸健，但是每次開發(fā)人員進(jìn)行更新時都會快速響應(yīng)，那么抱怨就會消失婉商。對代碼評審過程的大多數(shù)抱怨實(shí)際上是通過加快過程來解決的似忧。

代碼健康狀況會受到影響。當(dāng)評審速度較慢時丈秩，允許開發(fā)人員提交不如預(yù)期的CLs的壓力就會增加盯捌。緩慢的評審還會阻礙代碼清理、重構(gòu)和對現(xiàn)有CLs的進(jìn)一步改進(jìn)蘑秽。

代碼評審應(yīng)該有多快饺著？

如果您沒有集中精力完成任務(wù)箫攀，那么應(yīng)該在任務(wù)完成后不久進(jìn)行代碼檢查。

一個工作日是響應(yīng)代碼審查請求所需的最長時間（即第二天早上的第一件事）幼衰。

遵循這些指導(dǎo)原則意味著一個典型的CL應(yīng)該在一天內(nèi)(如果需要的話)進(jìn)行多輪評審靴跛。

速度與中斷

有一段時間，對個人速度的考慮超過了對團(tuán)隊速度的考慮渡嚣。如果你正在集中精力做一項(xiàng)任務(wù)梢睛，比如寫代碼，不要打斷自己去做codereview识椰。研究表明绝葡，開發(fā)人員在中斷開發(fā)之后，可能需要很長時間才能恢復(fù)到平穩(wěn)的開發(fā)流程裤唠。因此挤牛，對團(tuán)隊來說，在編寫代碼時打斷自己實(shí)際上比讓另一個開發(fā)人員等待code review的時間更昂貴种蘸。

相反墓赴，在你的工作中等待一個斷點(diǎn)，然后你才回應(yīng)一個審查的請求航瞭。這可能是當(dāng)你當(dāng)前的編碼任務(wù)完成時诫硕，午飯后，從會議回來刊侯，從微型廚房回來章办，等等。

快速反應(yīng)

當(dāng)我們討論代碼評審的速度時滨彻，我們關(guān)心的是響應(yīng)時間藕届，而不是CL完成整個評審并提交所需的時間。理想情況下亭饵，整個過程也應(yīng)該是快速的休偶，但是對于單個響應(yīng)的快速響應(yīng)比整個過程的快速響應(yīng)更重要。

即使有時需要很長時間才能完成整個評審過程辜羊，但是在整個過程中reviewer的快速響應(yīng)可以極大地減輕開發(fā)人員對“緩慢”code review的沮喪踏兜。

如果在一個CL提交過來時，你太忙了,難以做一個完整的review,你仍然可以發(fā)送一個快速反應(yīng),讓開發(fā)人員知道什么時候你會開始review,建議由其他reviewer來評審可以更快地響應(yīng)的效果,或者提供一些最初的粗略評論八秃。(注意:這并不意味著您應(yīng)該中斷編碼碱妆，即使是為了發(fā)送這樣的響應(yīng)—也應(yīng)該在您工作中的一個合理的斷點(diǎn)發(fā)送響應(yīng)。)

重要的是reviewer要花足夠的時間進(jìn)行評審昔驱，以確保他們的“LGTM”的意思是“這段代碼符合我們的標(biāo)準(zhǔn)”疹尾。然而，個人的反應(yīng)最好還是要快。

跨時區(qū)評論

當(dāng)處理時區(qū)差異時航棱，試著在作者還在辦公室的時候給出回應(yīng)睡雇。如果他們已經(jīng)回家了萌衬，那么在他們第二天回到辦公室之前饮醇，確保你的評估已經(jīng)完成。

LGTM評論

為了加快code review的速度秕豫，在某些情況下朴艰，reviewer應(yīng)該給出LGTM/Approval，即使他們還在CL上留下未解決的注釋混移。這是在以下兩種情況下完成的:

reviewer確信開發(fā)人員將適當(dāng)?shù)靥幚韗eviewer剩余的所有評論祠墅。

其余的更改是次要的，開發(fā)人員不一定非要完成歌径。

如果不清楚毁嗦，reviewer應(yīng)該指定他們想要的選項(xiàng)。

當(dāng)開發(fā)人員和reviewer處于不同的時區(qū)時回铛，使用帶有注釋的LGTM尤其值得考慮狗准，否則開發(fā)人員將會等待一整天，只為獲得“LGTM茵肃，批準(zhǔn)”腔长。

大型CLs

如果有人給你提交了一個非常大的CL，你不知道什么時候你能有時間去review它,你的典型的反應(yīng)應(yīng)該要求開發(fā)人員把CL分割成幾個較小的CLs,而不是一個巨大的CL必須一次性審查验残。這通常是可行的捞附，并且對reviewer非常有幫助，即使這需要開發(fā)人員做額外的工作您没。

如果CL無法分解為較小的CL鸟召，并且您沒有時間快速查看整個內(nèi)容，那么至少要對CL的整體設(shè)計寫一些評論并將其發(fā)送回開發(fā)人員以進(jìn)行改進(jìn)氨鹏。作為reviewer欧募，您的目標(biāo)之一應(yīng)該是始終取消阻止開發(fā)人員或使他們能夠快速采取某種進(jìn)一步的操作，而不會犧牲代碼運(yùn)行狀況喻犁。

Code review隨時間的改進(jìn)

如果您遵循這些指導(dǎo)原則槽片，并且對code review非常嚴(yán)格，那么您應(yīng)該會發(fā)現(xiàn)肢础，隨著時間的推移还栓，整個code review過程會變得越來越快。開發(fā)人員了解健康代碼需要什么传轰，并從一開始就向您發(fā)送非常棒的CLs剩盒，這使得需要的評審時間越來越少。reviewer學(xué)會快速響應(yīng)慨蛙，而不是在評審過程中添加不必要的延遲辽聊。但是不要為了提高速度而犧牲c(diǎn)ode review標(biāo)準(zhǔn)或質(zhì)量——從長遠(yuǎn)來看纪挎，這實(shí)際上不會使任何事情發(fā)生得更快。

緊急情況

在一些緊急情況下跟匆，CLs必須非骋彀溃快速地通過整個評審過程，并且不會嚴(yán)格按照質(zhì)量指南來要求它玛臂。但是烤蜕，請看看什么是緊急情況?用于描述哪些情況實(shí)際上符合緊急情況，哪些不符合緊急情況迹冤。

五讽营、 如何編寫code review 評語

摘要

對人友善

解釋你的觀點(diǎn)

在給出明確的指示與指出問題并讓開發(fā)人員決定之間保持平衡。

鼓勵開發(fā)人員簡化代碼或添加代碼注釋泡徙，而不僅僅是向您解釋復(fù)雜性

禮貌

一般來說橱鹏，禮貌和尊重是很重要的。并且您也要對review對象非常明了和有幫助堪藐。一種方法是確保您總是對代碼進(jìn)行評論莉兰，而從不對開發(fā)人員進(jìn)行評論（譯者注：對事不對人）。你不必總是遵循這個習(xí)慣庶橱，但是當(dāng)你說一些可能會讓人心煩意亂或有爭議的話時贮勃，你絕對應(yīng)該使用這個習(xí)慣。例如:

反例:“為什么您在這里使用線程苏章，但是沒有從并發(fā)中獲得任何好處?”

正例:“這里的并發(fā)模型增加了系統(tǒng)的復(fù)雜性寂嘉，但我看不到任何實(shí)際的性能優(yōu)勢。因?yàn)闆]有性能上的好處枫绅，所以這段代碼最好是單線程的泉孩，而不是使用多線程〔⒘埽”

解釋為什么

關(guān)于上面的正面示例寓搬，您將注意到的一件事是，它幫助開發(fā)人員理解您為什么要發(fā)表評論县耽。您并不總是需要在評審注釋中包含這些信息句喷，但是有時候，對于您的意圖兔毙、您所遵循的最佳實(shí)踐唾琼，或者您的建議如何改進(jìn)代碼健康狀況，給出更多的解釋是合適的澎剥。

提供指導(dǎo)

一般來說锡溯，修復(fù)CL是開發(fā)人員的責(zé)任，而不是review的責(zé)任。您不需要為開發(fā)人員提供解決方案的詳細(xì)設(shè)計或編寫代碼祭饭。

不過芜茵，這并不意味著review應(yīng)該毫無幫助。一般來說倡蝙，你應(yīng)該在指出問題和提供直接指導(dǎo)之間取得適當(dāng)?shù)钠胶饩糯Ｖ赋鰡栴}并讓開發(fā)人員做出決策通常有助于開發(fā)人員學(xué)習(xí)，并使code review變得更容易悠咱。它還可以產(chǎn)生更好的解決方案蒸辆，因?yàn)殚_發(fā)人員比reviewer更接近代碼。

但是析既，有時直接的指令，建議甚至代碼會更有幫助谆奥。Code review的主要目標(biāo)是獲得最佳的CL眼坏。第二個目標(biāo)是提高開發(fā)人員的技能，以便他們隨著時間的流逝需要越來越少的審查酸些。

接受解釋

如果您要求開發(fā)人員解釋一段您不理解的代碼宰译，這通常會幫助他們更清楚地重寫代碼。偶爾魄懂，在代碼中添加注釋也是一種適當(dāng)?shù)捻憫?yīng)沿侈，只要它不只是解釋過于復(fù)雜的代碼。

僅在code review工具中編寫的解釋對將來的代碼讀者沒有幫助市栗。它們只在少數(shù)情況下是可接受的缀拭，例如當(dāng)您正在review一個您不太熟悉的區(qū)域，并且開發(fā)人員僅僅解釋了一些代碼的顯而易見的內(nèi)容時填帽。

六蛛淋、 處理回退

有時開發(fā)人員會抵制code review。要么他們不同意你的建議篡腌，要么他們會抱怨你總體上過于嚴(yán)格褐荷。

誰是對的百新？

當(dāng)開發(fā)人員不同意您的建議時躏精，請先花點(diǎn)時間考慮一下它們是否正確狞换。 通常洞翩，開發(fā)人員比您更接近代碼苇倡，因此可能實(shí)際上他們對代碼的某些方面比您更了解一些秘遏。 他們的論點(diǎn)有意義嗎传藏？ 從代碼健康角度來看庇谆，這有意義嗎缀台？ 如果是這樣棠赛，請讓他們知道他們是對的，然后解決問題。

然而睛约，開發(fā)人員并不總是正確的鼎俘。在這種情況下，reviewer應(yīng)該進(jìn)一步解釋為什么他們認(rèn)為他們的建議是正確的辩涝。一個好的解釋不僅說明了對開發(fā)人員的回答的理解贸伐，也說明了為什么開發(fā)人員需要做出更改的附加信息。

特別是怔揩，當(dāng)reviewer認(rèn)為他們的建議將改善代碼的健康狀況時捉邢，如果他們認(rèn)為所產(chǎn)生的代碼質(zhì)量改進(jìn)能夠證明所要求的額外工作是合理的，那么他們應(yīng)該繼續(xù)提倡更改商膊。改善代碼健康狀況往往是一些小步驟伏伐。

有時候，為了讓開發(fā)人員真正理解您的一個建議之前晕拆，您需要花幾輪時間來解釋它藐翎。您只要確保始終保持禮貌，并讓開發(fā)人員知道您聽到了他們在說什么实幕，您只是不同意吝镣。

令開發(fā)人員不安

reviewer有時認(rèn)為，如果自己堅持要進(jìn)行改進(jìn)昆庇，開發(fā)人員會感到不安末贾。有時候開發(fā)人員確實(shí)會感到沮喪，但是這通常是很短暫的整吆，之后他們會非常感謝您幫助他們提高了代碼的質(zhì)量拱撵。通常，如果您在評論中表現(xiàn)得很有禮貌掂为，開發(fā)人員實(shí)際上一點(diǎn)也不會感到不安裕膀，而這種擔(dān)心只存在于您的腦海中。通常勇哗，令人不安的地方更多的是評論的編寫方式昼扛，而不是reviewer對代碼質(zhì)量的堅持。

稍后清理

回退的一個常見原因是開發(fā)人員（可以理解）想要完成任務(wù)欲诺。 他們不想僅僅為了獲得此CL而進(jìn)行另一輪審核抄谐。因此，他們說他們將在以后的CL中清除某些內(nèi)容扰法，因此您現(xiàn)在應(yīng)該LGTM此CL蛹含。 一些開發(fā)人員對此非常好，并會立即編寫后續(xù)的CL來解決此問題塞颁。 但是浦箱，經(jīng)驗(yàn)表明吸耿，開發(fā)人員在編寫原始CL之后花費(fèi)的時間越多，清理工作的可能性就越小酷窥。 實(shí)際上咽安，通常除非開發(fā)人員在當(dāng)前CL之后立即進(jìn)行清理，否則它永遠(yuǎn)不會發(fā)生蓬推。 這不是因?yàn)殚_發(fā)人員不負(fù)責(zé)任妆棒，而是因?yàn)樗麄冇泻芏喙ぷ饕觯謇砉ぷ鲄s在其他工作中被遺忘或遺忘沸伏。 因此糕珊，通常最好是堅持要求開發(fā)人員在代碼進(jìn)入代碼庫并“完成”之前立即清理其CL。讓人們“稍后清理”是代碼庫退化的一種常見方法毅糟。

如果CL引入了新的復(fù)雜性红选，在提交之前必須清理它，除非是緊急情況留特。如果CL暴露了周圍的問題纠脾，而這些問題現(xiàn)在還無法解決，開發(fā)人員應(yīng)該為清理工作提交一個bug文件蜕青，并將其分配給自己，這樣它就不會丟失糊渊。他們還可以選擇在引用已歸檔錯誤的代碼中編寫TODO注釋右核。

對嚴(yán)格的普遍抱怨

如果您以前有相當(dāng)松散的代碼評審，而現(xiàn)在您轉(zhuǎn)而進(jìn)行嚴(yán)格的評審渺绒，那么一些開發(fā)人員將會非常大聲地抱怨贺喝。提高代碼評審的速度通常會使這些抱怨逐漸消失。

有時宗兼，這些抱怨可能要花費(fèi)數(shù)月的時間才能消失躏鱼，但是最終，開發(fā)人員往往會看到嚴(yán)格的代碼審查的價值殷绍，因?yàn)樗麄儠吹阶约簬椭傻某錾a染苛。 有時，一旦發(fā)生某種事情主到，使嚴(yán)格的抗議者甚至成為您最堅強(qiáng)的支持者茶行，這會使他們真正地看到自己在增加的價值。

解決沖突

如果您遵循上述所有方法登钥，但是您仍然遇到您自己和開發(fā)人員之間無法解決的沖突畔师，請參閱代碼評審標(biāo)準(zhǔn)，了解有助于解決沖突的指導(dǎo)原則和原則牧牢。