雖然新的代碼要與現(xiàn)有代碼的風(fēng)格保持一致是很重要的，但這些東西幾乎不需要人工審核員來完成。人工審核員的成本很高，而且可以完成計(jì)算機(jī)無法完成的事情。檢查是否符合風(fēng)格標(biāo)準(zhǔn)是計(jì)算機(jī)可以輕松完成的事情，這就分散了代碼審核的真正目的。

如果開發(fā)人員在代碼審核過程中看到很多這樣的注釋，說明這個(gè)團(tuán)隊(duì)要么是沒有風(fēng)格指南，要么是有了風(fēng)格指南，但檢查風(fēng)格還沒有實(shí)現(xiàn)自動(dòng)化。解決的辦法是使用checkstyle等工具來確保風(fēng)格指南已經(jīng)被遵循，或者使用sonarqube來識(shí)別常見的質(zhì)量和安全問題。而不是依靠人工審核員來警告這類問題，持續(xù)集成環(huán)境可以做到這一點(diǎn)。

有時(shí)，如果沒有代碼指南，或者內(nèi)部代碼風(fēng)格隨著時(shí)間的推移而變化，在不同的部分有不同的風(fēng)格，那么這種自動(dòng)檢查可能會(huì)很困難。在這種情況下，有一些方法可以應(yīng)用自動(dòng)檢查。例如，一個(gè)團(tuán)隊(duì)可以同意做一個(gè)單一的提交，應(yīng)用約定的代碼風(fēng)格，并且不包含其他的更改?；蛘咭粋€(gè)團(tuán)隊(duì)可以約定，當(dāng)一個(gè)文件因?yàn)閎ug或功能而被更改時(shí)，該文件也會(huì)被更新到新的樣式，而自動(dòng)工具可以被配置為只檢查更改過的文件。

如果一個(gè)團(tuán)隊(duì)有多種代碼樣式，而它沒有辦法自動(dòng)檢查樣式，也容易落入下一個(gè)陷阱。

錯(cuò)誤模式：不一致的反饋

每一個(gè)被邀請(qǐng)審閱代碼的開發(fā)者，至少要多邀請(qǐng)一個(gè)意見，而且可能更多。每個(gè)人都可以同時(shí)持有不止一種意見。有時(shí)，Code Review 可能會(huì)陷入審查者之間關(guān)于不同方法的爭論，比如說是使用流還是經(jīng)典的for循環(huán)最好。如果團(tuán)隊(duì)成員對(duì)同一段代碼有不同的意見，那么開發(fā)人員應(yīng)該如何進(jìn)行修改，結(jié)束審閱，并將代碼推送到生產(chǎn)中？

即使是一個(gè)審稿人的想法也很容易發(fā)生變化，可能是在一次審稿中，也可能是在一系列的審稿中。在一次審閱中，一個(gè)審閱者可能會(huì)催促作者確保使用O(1)讀操作的數(shù)據(jù)結(jié)構(gòu)，而在下一次審閱中，審閱者可能會(huì)問為什么不同的用例會(huì)有幾個(gè)數(shù)據(jù)結(jié)構(gòu)，并建議通過單一結(jié)構(gòu)進(jìn)行線性搜索來簡化代碼。

當(dāng)一個(gè)團(tuán)隊(duì)對(duì)自己的 "最佳實(shí)踐 "是什么樣子的沒有一個(gè)明確的想法，當(dāng)團(tuán)隊(duì)還沒有弄清楚自己的優(yōu)先級(jí)是什么的時(shí)候，這種情況就會(huì)出現(xiàn)：

幾乎所有的設(shè)計(jì)問題都可以用 "這要看情況 "來回答。為了對(duì)答案有一個(gè)更好的想法，開發(fā)人員需要了解他們的應(yīng)用和團(tuán)隊(duì)的優(yōu)先級(jí)。

錯(cuò)誤模式：最后一分鐘的設(shè)計(jì)變更

開發(fā)者在Code Review 過程中最讓人士氣低落的反饋是：當(dāng)評(píng)審者從根本上不同意方案的設(shè)計(jì)或架構(gòu)，并強(qiáng)行完全重寫代碼時(shí)，要么通過一系列的評(píng)審來逐步完成（見下一節(jié)），要么粗暴地拒絕代碼，讓作者重新開始。

Code Review 不是評(píng)審設(shè)計(jì)的正確時(shí)機(jī)。如果團(tuán)隊(duì)按照經(jīng)典的 "網(wǎng)關(guān)式 " Code Review ，那么在最后一步讓另一個(gè)開發(fā)人員看代碼之前，代碼應(yīng)該是可以工作的，所有的測(cè)試都應(yīng)該是通過的。在這一點(diǎn)上，幾個(gè)小時(shí)、幾天，甚至可能是幾周（雖然我真的希望不是幾周；Code Review 應(yīng)該是小事一樁，但這是另一個(gè)話題）的努力已經(jīng)花在了被審查的代碼上。在Code Review 中指出底層設(shè)計(jì)是錯(cuò)誤的，這是在浪費(fèi)大家的時(shí)間。

Code Review 可以作為設(shè)計(jì)審查，但如果這是Code Review 的意圖，那么審查應(yīng)該在實(shí)現(xiàn)之初就進(jìn)行。然后，在開發(fā)人員還沒有走得太遠(yuǎn)之前，他們可以把自己的想法勾勒出來，也許會(huì)有一些存根類和方法，以及一些有意義的名稱和步驟的測(cè)試，也許還可以提交一些文字或圖表，以便讓團(tuán)隊(duì)成員對(duì)將要采取的方法進(jìn)行反饋。

如果團(tuán)隊(duì)成員在關(guān)口審查中發(fā)現(xiàn)了真正的展示性設(shè)計(jì)問題（也就是說，當(dāng)代碼完成并運(yùn)行時(shí)），團(tuán)隊(duì)?wèi)?yīng)該更新流程，以便更早地定位這些問題。這可能意味著要做其他類型的審查，比如上一段中建議的審查，白板上的想法，配對(duì)編程，或者與技術(shù)負(fù)責(zé)人討論建議的解決方案。在最后的Code Review 中發(fā)現(xiàn)設(shè)計(jì)問題是對(duì)開發(fā)時(shí)間的浪費(fèi)，也是對(duì)代碼作者的極大打擊。

錯(cuò)誤模式：乒乓球 Reviews

在一個(gè)理想的世界里，作者會(huì)提交代碼進(jìn)行評(píng)審，評(píng)審人員會(huì)提出一些明確的解決方案的意見，作者提出修改建議并重新提交代碼，評(píng)審結(jié)束，代碼就會(huì)被推送。但如果這樣的事情經(jīng)常發(fā)生，誰還能說得清 Code Review 的過程是有道理的呢？

在現(xiàn)實(shí)生活中，經(jīng)常出現(xiàn)的情況是這樣的：

在這個(gè)過程中，理論上來說，修改和批注應(yīng)該向著零的方向下降，直到代碼準(zhǔn)備好為止。最郁悶的情況是，每一次迭代都會(huì)帶來至少和已經(jīng)結(jié)束的舊問題一樣多的新問題。在這種情況下，團(tuán)隊(duì)就進(jìn)入了 "Code Review 的無限循環(huán)"。發(fā)生這種情況的原因有很多：

評(píng)論應(yīng)該被理解為阻止者或不是阻止者，如果審稿人決定代碼需要修改，他們需要明確說明代碼作者應(yīng)該采取什么行動(dòng)。

同樣重要的是，要明白由誰來決定審核是否 "完成"。這可以通過任務(wù)清單上的檢查項(xiàng)目來實(shí)現(xiàn)，也可以由個(gè)人授權(quán)說 "足夠好 "來完成。通常需要有一個(gè)人能夠打破僵局，解決分歧。這個(gè)人可能是高級(jí)開發(fā)人員、領(lǐng)導(dǎo)或者是架構(gòu)師，甚至是團(tuán)隊(duì)中的代碼作者，因?yàn)樵趫F(tuán)隊(duì)中，他們之間的信任度很高。但是，在某些時(shí)候，需要有人說 "評(píng)審結(jié)束了 "或者 "當(dāng)這些步驟完成后，評(píng)審就結(jié)束了。"

錯(cuò)誤模式：幽靈審查

在這里我承認(rèn)我最容易犯的反常的地方：幽靈化。無論我是審閱者還是代碼作者，在代碼審閱中都會(huì)出現(xiàn)一個(gè)點(diǎn)（有時(shí)就在開始的時(shí)候！），在審閱過程中，我根本就沒有回應(yīng)。也許有一個(gè)重要或有趣的功能被要求我審閱，所以我決定把它留到 "更好的時(shí)候"，等我可以 "真正好好看一看 "的時(shí)候再做。又或許是Review的量大，我想留出充足的時(shí)間。又或許是我是作者，在迭代（或二十次）后，我就是無法面對(duì)閱讀和回復(fù)評(píng)論了，所以我決定等 "等我的腦袋想好了再來"。

聽起來是不是很熟悉？

不管是什么原因，有時(shí)在審查過程中有人根本沒有反應(yīng)。這可能意味著在這個(gè)人看完代碼之前，審查工作就已經(jīng)死氣沉沉了。這是一種浪費(fèi)。即使有人在創(chuàng)建一個(gè)資產(chǎn)（新代碼）上投入了時(shí)間，但在它投入生產(chǎn)之前，它并沒有增加價(jià)值。事實(shí)上，當(dāng)它在代碼庫中越來越落后于其他代碼庫的時(shí)候，它很可能已經(jīng)腐爛了。

有幾個(gè)因素會(huì)導(dǎo)致幽靈審查。龐大的代碼審核量是一個(gè)因素，因?yàn)檎l愿意去翻閱幾十個(gè)或幾百個(gè)修改過的文件？不重視Code Review 是另一個(gè)因素，因?yàn)椴恢匾旵ode Review 是真正的工作或交付成果的一部分。困難的或令人沮喪的Code Review 經(jīng)歷是另一個(gè)主要因素。沒有人愿意停止編碼（開發(fā)人員通常喜歡的東西），去參加一項(xiàng)耗費(fèi)時(shí)間和破壞靈魂的活動(dòng)。

以下是解決幽靈審查的建議：

最后一點(diǎn)可能需要團(tuán)隊(duì)的紀(jì)律性，或者團(tuán)隊(duì)可能希望通過（例如）通過目標(biāo)或任何用來決定開發(fā)人員的生產(chǎn)力的機(jī)制來獎(jiǎng)勵(lì)良好的Code Review 行為來鼓勵(lì)允許時(shí)間。

你的團(tuán)隊(duì)能做什么？

對(duì)于研發(fā)團(tuán)隊(duì)，專注于創(chuàng)建一個(gè)行之有效的Code Review流程。我在我的博客上寫過這方面的內(nèi)容，但想在這里分享一下這個(gè)過程的一部分：

團(tuán)隊(duì)為什么要做審閱？當(dāng)有一個(gè)明確的目的時(shí)，審查員的工作會(huì)更容易，代碼作者也會(huì)從審查過程中減少討厭的驚喜。團(tuán)隊(duì)成員要找的是什么？當(dāng)有了目的，開發(fā)人員可以在審閱代碼時(shí)創(chuàng)建一套更有針對(duì)性的東西來檢查。誰來參與？誰來做評(píng)審，誰負(fù)責(zé)解決意見沖突，誰最終決定代碼是否合格？團(tuán)隊(duì)何時(shí)進(jìn)行復(fù)審，復(fù)審何時(shí)完成？審核可以在開發(fā)人員在代碼工作的時(shí)候迭代進(jìn)行，也可以在流程結(jié)束時(shí)進(jìn)行。如果沒有明確的指導(dǎo)，一個(gè)評(píng)審可能會(huì)一直進(jìn)行下去，如果沒有明確的指導(dǎo)，代碼最終什么時(shí)候可以進(jìn)行。團(tuán)隊(duì)在哪里做評(píng)審？Code Review 不需要特定的工具，所以審查可能就像作者在辦公桌上帶領(lǐng)同事看他們的代碼一樣簡單。

一旦回答了這些問題，你的團(tuán)隊(duì)就應(yīng)該能夠創(chuàng)建一個(gè)運(yùn)行良好的Code Review 流程。記住：Code Review 的目的應(yīng)該是讓代碼投入生產(chǎn)，而不是證明開發(fā)人員有多聰明。

結(jié)論

Code Review 的錯(cuò)誤模式可以通過建立一個(gè)明確的Code Review 流程來消除，或者至少是緩解。許多團(tuán)隊(duì)認(rèn)為他們應(yīng)該進(jìn)行Code Review ，但他們沒有明確的準(zhǔn)則，為什么要進(jìn)行Code Review 。

不同的團(tuán)隊(duì)需要不同類型的Code Review ，就像不同的應(yīng)用程序有不同的業(yè)務(wù)和性能要求一樣。第一步是弄清楚團(tuán)隊(duì)為什么需要審閱代碼，然后團(tuán)隊(duì)就可以著手于：

專注于為什么要進(jìn)行Code Review ，將幫助團(tuán)隊(duì)創(chuàng)建Code Review 流程的最佳實(shí)踐，這樣就更容易避免Code Review 的錯(cuò)誤模式。