1、code review

code review發(fā)音

英：　　美：

code review中文意思翻譯

常用釋義：代碼審查：指的是識別和驗證算法選擇、編碼風(fēng)格以及與軟件設計的一致性的實(shí)踐或實(shí)例。

代碼評審

代碼審查

code review雙語(yǔ)使用場(chǎng)景

1、Take your time with code review.───您要花點(diǎn)時(shí)間進(jìn)行代碼評審。

2、Able to follow the company coding guidelines and to lead the code review session.───能夠遵守公司的編碼規范并進(jìn)行代碼審查。

3、The purpose of Code Review Details is to provide a description of the finding, examples, and suggestion for the fix, as shown in Figure 4.───CodeReviewDetails的目的是提供結果和樣例的描述，以及解決的建議，如圖4所示。

4、Nobody is above a code review.───沒(méi)有人能夠凌駕于代碼評審之上。

5、Through plenty of coding and code review to realize efficient infrastructure of applications in terms of code-size, memory, and storage.───通過(guò)大量的編碼與審閱，在代碼大小，內存及存儲層面認識理解應用的基礎架構。

6、We used the information gleaned through years of experience to create the concept of lightweight code review.───我們通過(guò)數十年的經(jīng)驗使用獲得的信息，來(lái)創(chuàng )建輕量級代碼評審的概念。

7、Code review can be automated.───可以實(shí)現代碼檢查自動(dòng)化。

8、Add some sort of manual code review capability to the platform for adding, suppressing, commenting, and discussing quality defects.───為平臺添加手工代碼審查能力，可以添加、抑制、注釋和討論質(zhì)量缺陷。

9、Frequent code review is also a must, and finally, coding policies need to be enforced, he said.───頻繁的代碼檢查也是必須進(jìn)行的，而最后，編程方針需要進(jìn)一步被強化。

code review相似詞語(yǔ)短語(yǔ)

1、rave reviews───哄動(dòng)熱烈的好評；狂熱褒評

2、mixed review───混合評論

3、fake review───虛假評論

4、case review───審查案件

5、book reviews───書(shū)評

6、rave review───哄動(dòng)熱烈的好評；狂熱褒評

7、to review───回顧；復習

8、clear view───清晰視界

9、book review───書(shū)評

2、Code Review常見(jiàn)的5個(gè)錯誤模式？

Code Review 的時(shí)候，每個(gè)人都會(huì )關(guān)心最佳實(shí)踐，但最壞的實(shí)踐有時(shí)可能會(huì )更有啟示意義。

Code Review是研發(fā)團隊必不可少的，但并不總是正確的。這篇文章指出了所有開(kāi)發(fā)者在Code Review時(shí)或提交拉取請求時(shí)可能都會(huì )遇到的一些常見(jiàn)的錯誤模式，并對這些錯誤模式進(jìn)行了總結：

錯誤模式：挑毛病

想象一下下面的場(chǎng)景。代碼作者花了幾個(gè)小時(shí)，甚至幾天的時(shí)間來(lái)創(chuàng )建他們認為最有效的解決方案。他們考慮了多種設計方案，并選擇了看起來(lái)最相關(guān)的路徑。他們考慮了現有應用程序的架構，并在適當的地方進(jìn)行了修改。然后，他們將自己的解決方案以拉動(dòng)請求的形式提交，或者開(kāi)始了代Code Review 過(guò)程，他們收到的專(zhuān)家反饋是：

"你應該使用標簽，而不是空格。""我不喜歡這部分的大括號在哪里。""你的文件末尾沒(méi)有空行。""你們的詞庫是大寫(xiě)的，應該用句子大寫(xiě)。"

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

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

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

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

錯誤模式：不一致的反饋

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

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

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

代碼是否應該向著(zhù)更現代的Java風(fēng)格發(fā)展？還是更重要的是代碼的一致性，因此，繼續到處使用 "經(jīng)典 "構造？在系統的所有部分中，對數據結構進(jìn)行O(1)讀操作是否重要？還是有些部分的O(n)可以接受？

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

錯誤模式：最后一分鐘的設計變更

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

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

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

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

錯誤模式：乒乓球 Reviews

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

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

一個(gè)Code Review開(kāi)始了。一些審稿人提出了幾個(gè)建議：有的小而容易，有的蓬頭垢面，沒(méi)有明顯的解決方案，有的復雜。作者做了一些修改：至少是簡(jiǎn)單的修改，或者說(shuō)是幾處修改，力求讓審稿人滿(mǎn)意。作者可能會(huì )向審稿人提出問(wèn)題來(lái)澄清一些事情，或者作者可能會(huì )提出意見(jiàn)，解釋為什么沒(méi)有做出特定的修改。審稿人回來(lái)后，接受一些更新，對其他的修改提出進(jìn)一步的意見(jiàn)，找到他們不喜歡的地方，回答問(wèn)題，并在審稿中與其他審稿人或作者爭論他們的意見(jiàn)。代碼作者做更多的修改，增加更多的評論和問(wèn)題，以此類(lèi)推。審稿人檢查修改，提出更多的意見(jiàn)和建議，以此類(lèi)推。步驟5和6重復進(jìn)行，或許永遠都是這樣。

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

如果審稿人吹毛求疵，如果審稿人給出的反饋不一致，就會(huì )出現這種情況。對于陷入這些習慣的審稿人來(lái)說(shuō)，有無(wú)限多的問(wèn)題需要找出，有無(wú)限多的意見(jiàn)需要提出。當審稿時(shí)沒(méi)有明確的審稿目的，或者審稿時(shí)沒(méi)有準則可循，就會(huì )出現這種情況，因為這樣一來(lái)，每個(gè)審稿人都會(huì )覺(jué)得每一個(gè)可能出現的問(wèn)題都必須找出來(lái)。當不清楚審稿人的評論對代碼作者的要求是什么時(shí)就會(huì )發(fā)生。是不是每一條評論都意味著(zhù)必須要進(jìn)行修改？所有的問(wèn)題是否都暗示著(zhù)代碼沒(méi)有自證，需要改進(jìn)？還是有些評論僅僅是為了教育代碼作者下一次，而提出問(wèn)題只是為了幫助審稿人理解和學(xué)習？

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

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

錯誤模式：幽靈審查

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

聽(tīng)起來(lái)是不是很熟悉？

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

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

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

確保Code Review 的規模要小。每個(gè)團隊都要制定出自己的定義，但這將是幾個(gè)小時(shí)或幾天的復審工作，而不是幾周的時(shí)間。確保Code Review 的目的很明確，審查人員應該找的東西很清楚。當范圍是 "找到代碼中可能存在的任何問(wèn)題 "時(shí)，很難激勵自己去做一件事。"在開(kāi)發(fā)過(guò)程中留出時(shí)間來(lái)做Code Review 。

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

你的團隊能做什么？

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

在進(jìn)行Code Review 時(shí)，有很多事情需要考慮，如果開(kāi)發(fā)人員在每次Code Review 時(shí)都擔心所有的事情，那么任何代碼都幾乎不可能通過(guò)評審流程。要實(shí)現一個(gè)適合所有人的Code Review 流程，最好的方法是考慮以下問(wèn)題。

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

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

結論

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

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

自動(dòng)化的簡(jiǎn)易檢查（例如，檢查代碼樣式，識別常見(jiàn)的BUG，發(fā)現安全問(wèn)題）。就審查的時(shí)間、審查的內容以及審查結束后由誰(shuí)決定等問(wèn)題制定明確的準則將Code Review 作為開(kāi)發(fā)過(guò)程的一個(gè)關(guān)鍵工作內容

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