導語：Google 前幾天公開了一篇谷歌的工程實踐文檔，內容跟 code review 相關，里面包含了 Google 工程師如何進行 code review 的內容，以及 code review 指南。筆者將其轉譯成中文，以便大家參考學習。

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

本文的名詞解釋：

• cr: code review

• cl: change list，指這次改動

• reviewer: cr的那個review人

• nit: 全稱nitpick，意思是雞蛋里挑骨頭

• 作者: 也就是本次CL的開發者，原文中是以author來稱開發者的。

如果嫌文章太長，可以直接拖到文章最后看總結

cr的標準

cr(Code review)主要目的在于確保Google 的代碼庫代碼質量越來越好。而所有相關的工具與流程皆是因應這個目的而生。為達到此目的，勢必需要做出一連串的權衡與取舍。

首先，開發人員必須能夠在自己負責的任務上有所進展。如果你從來沒有向代碼庫提交改進過的代碼，那么代碼庫就永遠不會改進。另外，如果一個reviewer使cr都很難進行的話，那么開發人員就不愿意在將來進行改進。

另一方面，reviewer有責任確保每個change list（下稱CL）的質量，保證其代碼庫的整體代碼質量不會越來越差。這可能很棘手，因為通常會隨著時間的推移，代碼需要降級才能讓代碼運行起來，特別是當團隊受到嚴重的時間限制時，大家覺得必須走捷徑才能實現他們的目標。

此外，reviewer對他們正在review的代碼擁有所有權和責任。他們希望確保代碼保持一致、可維護，以及下文的“在cr中可以得到什么”中提到的內容。

因此，我們有以下規則，作為我們在cr中所期望的標準：

一般來說，當CL存在的時候，reviewer應該贊成它，此時它肯定會提高正在工作的系統的整體代碼質量，即使這個CL并不完美。這是所有cr中的首要原則。當然，這是有局限性的。例如，如果一個CL添加了一個reviewer不希望在其系統中使用的功能，那么reviewer當然可以拒絕，即使代碼設計得很好。

這里的一個關鍵點是，沒有“完美”的代碼，只有更好的代碼。reviewer不應該要求作者在approve之前對一篇文章的每一小段進行潤色。相反，reviewer應該權衡發展的需要和他們所建議的change的重要性。reviewer不應追求完美，而應追求持續改進。作為一個整體，提高系統的可維護性、可讀性和可理解性的CL不應該因為它不是“完美的”而被延遲幾天或幾周。

reviewer應該隨時可以留下評論，表達一些更好的東西，但如果不是很重要，可以在評論前加上“nit:”這樣的前綴，讓作者知道這只是一個他們可以選擇忽略的修飾點。

指導

cr有一個重要的功能，教開發人員一些關于語言、框架或一般軟件設計原則的新知識。留下有助于開發人員學習新知識的評論是可以的。隨著時間的推移，共享知識是提高系統代碼健康度的一部分。你只需要記住，如果你的評論純粹是教育性的，但對達到本文檔中描述的標準并不重要，請在其前面加上“nit:”，或者以其他方式表明作者不必在本CL中解決它。

原則

現實和數據推翻了個人喜好。在代碼風格方面，風格指南（style guide）是絕對的權威。任何不在style guide中的一些點（如空格等）都是個人偏好的問題。代碼風格應該與現有的一致。如果項目沒有以前的統一風格，那就接受作者的風格。

軟件設計的各個方面從來都不僅僅是一個純粹的代碼風格問題或者是個人喜好問題。它們是以基本原則為基礎的，應當以這些原則為依據，而不僅僅是以個人意見為依據，有時幾乎都沒有選擇的。如果作者能夠證明（通過數據或基于原理的一些事實）他的方法是同樣有效的，那么reviewer應該接受作者的偏好。否則，代碼風格選擇取決于軟件設計的標準原則。

如果沒有其他規則適用，那么reviewer可以要求作者與當前代碼庫中的內容保持一致，只要這些代碼不會惡化系統的整體代碼健康狀況。

解決沖突

在cr的任何沖突中，第一步應該始終是開發人員和reviewer根據本文和《CL Author’s Guide》，嘗試達成共識。

當達成共識變得特別困難時，reviewer和作者需要進行面對面會議，而不是僅僅試圖通過cr的注釋來解決沖突（不過，如果這樣做，請確保將討論結果記錄在CL的評論中，以供將來的讀者閱讀）。

如果這不能解決問題，最常見的解決方法就是升級。通常情況下，升級的途徑是進行更廣泛的團隊討論，讓team leader參與進來，請求代碼維護人員做出決定，或者請求技術經理提供幫助。不要因為作者和審稿人不能達成一致意見而讓一個其他人袖手旁觀。

在cr中要看些什么

注意：在考慮每一點時，一定要考慮cr的標準。

設計

在cr中重要的是看CL的總體設計。CL中不同代碼段的交互是否有意義？此更改屬于你的業務代碼庫還是屬于引進來的其他代碼庫？它是否與系統的其他部分很好地集成？現在是添加此功能的合適時機嗎？

功能

這個CL做了開發者想要的嗎？開發者對這些代碼的設計初衷用戶有好處嗎？“用戶”通常既是最終用戶（當他們受到更改的影響時）又是開發人員（他們將來必須“使用”此代碼）。

大多數情況下，我們希望開發人員在進行cr時能夠對CL進行充分的測試，使其能夠正常工作。但是，作為reviewer，仍然應該考慮邊緣狀況，尋找問題，嘗試像用戶一樣思考，并確保僅通過閱讀代碼就不會看到錯誤。

如果你愿意的話，你可以自己去驗證CL。如果改動會直接帶來的用戶可見的影響，比如說ui改動，驗證CL的變化是非常關鍵的。

在閱讀代碼時，很難理解某些更改會對用戶產生怎樣的影響。對于這樣的更改，如果不方便自己測試，則可以讓開發人員演示該功能(demo)。

另外，在cr期間考慮功能性特別重要的點是，cl中是否并發式編程，理論上可能導致死鎖或競爭條件。這些類型的問題很難通過運行代碼來發現，通常需要有人（開發人員和reviewer）仔細考慮，以確保不會引入問題（注意，這也是不使用平行式編程的一個很好的理由，在這種情況下，可能出現競爭條件或死鎖，這會使代碼檢查或理解代碼變得非常復雜）。

復雜性

一個CL是否復雜到超過預期的必須？針對任何層級的CL必須確認這幾點：單行代碼是否過于復雜？函數是否過于復雜？class是否過于復雜？“復雜”通常意味著該代碼很難閱讀，很有可能也意味著其他開發者在修改這段代碼的時候引入其他bug。

其中一種復雜性就是過度設計(Over-engineering)造成的，開發者會讓那段代碼過度通用化，超過了原本所需，或者還新增了系統目前不需要的功能。reviewer應特別注意一下過度設計。鼓勵開發者解決他們知道現在需要解決的問題，而不是推測將來可能需要解決的問題。當那些將來出現的問題出現的時候才開始解決它們，因為那時候你可以更加清晰看見問題的原樣子。

Donald Knuth說過：過早的優化是萬惡之源 (Premature optimization is the root of all evil)。

測試

請將單元測試、整合測試、端到端測試視為要求CL所做的適當變更。一般CL內除了生產環境的業務代碼外，測試也應該要被加入其中。除非該CL是為了處理某個緊急事情而存在。

另外，也要確保測試是正確、合理、有用的。測試并非來測試它們本身，一般也極少為了測試而測試（如測試一下測試代碼有沒有問題又走了測試流程），因此我們要保證測試是有效的。

當代碼真的有問題，測試是否會失敗？如果被測試的程序發生改動時，測試是否會產生誤報？每一個測試是否做出了簡單而有用的斷言？不同的測試方法之間的測試是否適當分開？

請記住，測試代碼也是必須維護的代碼，不要因為它們不在主要關注的范圍內。

命名

開發者是否為了每一個東西都挑了一個適當的名字？一個好的命名意味著，通過名字就足以完整表達該東西的作用是什么或者要做什么。但是同時名字也不要長得難以閱讀。

推薦參考文章：Clean code 101 — Meaningful names and functions

注釋

開發者是否用可理解的英文留下清晰的注釋? 這些注釋是否真的必要?

通常注釋是解析這段代碼為什么存在的時候是相當有用的，而不應該去解釋某段代碼正在做什么。如果代碼本身不能解釋清楚的話，意味著它更加需要簡化了。當然也有例外，比如解釋正規的表達式或者復雜的算法正在做什么的時候，注釋解釋這段代碼正在做什么就相當有用。但對于大部分注釋來說是用來說明那些不包含在程序本身但資訊，比如說為什么要這樣子做的理由。

查看該CL之前的注釋也很有幫助，或許有一個todo項目現在可以一處、一個評論建議為什么不要進行這種更改等等。

要注意的是，注釋與class、module、function的文件不同。后三者要能夠表達一段代碼的目的、如何使用它、使用時行為。

風格

Google 對于主要語言都有提供風格指南（style guide），甚至包括大多數冷門語言，因此要確保CL遵循適當的指南上的說明。

如果你想改進CL中某些不包含在風格指南中的要點時，請在評論前加上Nit: ，讓開發人員知道這是你認為可以改善代碼的小問題且并非強制性的。但記住，不要僅根據個人風格偏好阻止提交CL。

開發者不應該在 CL內同時包含主要風格的改動與其他代碼的修改，這樣會導致難以看出CL到底做出什么改動。同時也會讓合并和回滾更為復雜，并產生其他問題。例如，如果作者想要重新格式化代碼的話，讓他們將新格式在一個新CL里面重構。

文檔

如果CL更改了構建、測試、交互、發布的時候，請檢查是否也同時更新相關文檔， 包括README，g3doc 頁面和其他生成(generated) 的參考文件。如果CL 刪除或棄用 了一些代碼，請考慮是否應該刪除對應文檔，如果缺少文檔時請詢問。

每一行代碼

仔細review分配給你的每一行代碼。有些東西，比如資料文件(data files)、生成的代碼(generated code)、大型數據結構(large data structures)，你可以稍微掃過。千萬不要在掃過開發者寫的 class、函數、代碼區塊 時，去假設它內部是沒問題的。很顯然的某些代碼需要比其他代碼更仔細的review。這是必須由你做出的判斷，但至少你應該確定你理解所有代碼在做些什么。

如果閱讀代碼過于復雜并且減慢review速度時，那么你再繼續review前，要讓開發者知道這件事，并等待他們為這段代碼做出解釋、說清楚。在Google 我們聘請許多優秀的軟件工程師，而你也是其中的一員。如果連你也無法理解的話，很可能其他人也不會。因此，你要求開發者去說清楚這段代碼時，同時也在幫助未來的開發人員理解這些代碼。

如果你能夠理解，但覺得沒有資格進行某部分的審核，請確保 reviewer中有一個適合(合格) 的人來review該部分。尤其是針對安全性、并發性、可訪問性、國際化等復雜問題時。

上下文

在充足的上下文下查看CL通常很有幫助。一般來說，cr工具只會顯示修改部分周圍的幾行代碼而已。但有時你必須查看整個文件以確保改動是否合理。比方說，你可能只看到添加4行新代碼，但實際上查看整個文件時會發現這4行是被加在有50行的代碼里，此時需要將它拆解為更小的函數。

以整個系統的角度出發來思考CL也是很有用的。該CL是否改善整體系統的代碼質量，亦或是會讓整個系統更加復雜？是否缺少測試？千萬不要接受會降低整體系統的代碼質量的CL。因為大多數系統是由于許多小改動的積累而變得復雜，因此阻止新的改動引入復雜性(盡管很小)也非常重要。

優點

當你在CL里看到優點時記得告訴開發者，尤其是當他們用很棒的方式來解決你的評論時。cr通常只關注存在的錯誤，但它們也應該同時應該為良好實踐提供鼓勵與欣賞。這點在指導開發者時尤其重要:與其告訴他們做錯什么，還不如告訴他們做對了什么。

個人認為并非不要指出錯誤，而是多以鼓勵來代替指出錯誤，讓其他開發者更有動力想將事情做好。其實透過簡單的一句話讓對方知道哪里做得很好，未來他們會將繼續保持下去，并為其他開發者帶來的正面影響。

標明每個commit 修改什么，幫助reviewer快速了解情況

此時就不要吝嗇你的稱贊了!

總結

在cr時，請務必確保：

• 代碼經過完善的設計
• 功能性對于使用者們是好的
• 對于任何UI改動要合理且好看
• 任何并行編程的實現是安全
• 代碼不應該復雜超過原本所必須的
• 開發者不該實現一個現在不用而未來可能需要的功能
• 代碼有適當的單元測試
• 測試經過完善的設計
• 開發者對于每樣東西有使用清晰、明了的命名
• 注釋要清楚且有用，并只用來解釋why而非what
• 代碼有適當的寫下文件(一般在g3doc)
• 代碼風格符合style guide
• 確保你查看被要求review的每一行代碼、確認上下文、確保你正在改善代碼質量，并贊揚開發人員所做的好事與優點吧！
  

如何瀏覽CL

現在你已經知道review時要看些什么，但怎樣才是review分散在多個文件中的改動最有效的方法？

改動是否合理？他是否有好的描述(description)

優先看CL 最重要的改動。它整體是否有完善的設計？

用合理的順序看CL 剩余的改動

步驟1: 用宏觀的角度來看待改動，查看CL描述以及它做什么

該改動是否有意義、合理？如果在第一時間認為不應該發生這種變化，請立即說明為什么不該這樣做的原因。當拒絕類似這樣的更改時，向開發人員提供建議告訴他們應該怎么做什么也是一個好主意。

例如，你可以說：“看起來你已經完成一些不錯的事情，謝謝!但我們實際上正朝著刪除你正在修改的FooWidget系統的方向前進，所以現階段我們不想對它進行任何新的修改。不如重構我們的新BarWidget class如何？”

需要注意的是，reviewer在委婉拒絕該CL的同時也要提供替代方案，而且仍然保持禮貌。這種禮貌是很重要，因為我們希望表明即使不同意也會相互保持尊重。

如果你有幾個CL里包含你不想這樣做的改動時，你應該重新考慮開發團隊的開發過程，或發布開發流程給外部貢獻者知道，以便在任何CL被撰寫前有更多的溝通。最好是在他們開始投入前說“不”，避免那些已經投入心血的工作現在必須被拋棄或徹底重寫。

提供替代方案讓對方知道該怎么做，而非讓其自行獨自摸索。

指出問題，告知替代方案或指點方向

步驟2: 檢查CL主要的部分

找到CL最核心的部分的那些文件。通常CL內會有文件包含大量的邏輯改動，而它正是CL的主要部分。因此我們要首先查看這些主要部分。這有助于為CL的其他較小部分提供適當上下文，而且這樣通?？梢蕴岣遰eview速度。如果CL太大導致于無法確定哪里是主要部分時，請向開發者詢問首先應當查看的內容，或者要求他們將CL拆分為多個CL。

如果在主要部分發現存在一些主要的設計問題時，即使沒有時間立即查看CL的其余部分，也應立即留下評論告知此問題。因為事實上，因為該設計問題足夠嚴重的話，繼續review其他部分的代碼可能只是浪費時間，因為其他正在審查的其他代碼可能都將無關緊或消失。

立刻發送關于主要設計的評論非常重要有兩個主要原因：

• 通常開發者在送出CL后，在等待review過程中便已經開始著手基于該CL的新工作。此時如果正在review的CL存在重大設計問題的話，開發者將不得不重新寫所有基于它的后續所有CL。因此你要在他們有問題的設計上投入之前阻止他們。
• 主要設計變更通常需要較長時間才能完成，但每個開發人員幾乎都有自己deadline。為了趕上deadline并保證代碼質量，開發者需要盡快開始或重做CL 任何的主要設計變更。

步驟3: 用合理的順序看CL 其余的改動

一旦確認整個CL沒有重大的設計問題時，試著找出一個有邏輯順序來review剩余檔案，并確保不會錯過其中任何一個。通常在瀏覽主要部分后，最簡單的方式是按照cr工具提供的順序來瀏覽每個文件。有時在閱讀主要代碼前先閱讀測試也是非常有幫助的，如此一來你就可以了解應該做、看些什么。

review的速度

為什么review速度要快

在Google我們優化開發團隊共同生產產品的速度，而不是優化個人開發的速度。個人的開發速度很重要，但它不如整個團隊的開發速度重要。當cr很慢時，會發生以下幾件事：

• 團隊整體的速度下降。review慢的話，對于團隊其他人來說重要的新功能與缺陷修復將會被延遲數天、數周甚至數月，只因為它們正在或者等待review。
• 開發人員開始抗議cr。若reviewer每隔幾天才回應一次，但每次都要求對CL進行重大更改的話，那么開發人員可能會感到非常沮喪與覺得困難，而這通常會演變成抱怨。如果reviewer請求相同的實質性更改(且確實可以改善代碼質量狀況)，但在每次開發人員提交新的改動時都能快速反應的話，這些抱怨往往會消失。大多數關于cr的抱怨，往往可以通過加快流程來解決。
• 代碼質量會受到影響。當review很慢時，會造成開發者提交不完全盡如人意的CL 的壓力越來越大。評論的越慢也會阻止他人進行代碼清理、重構、甚至是對現有CL 的進一步改進。

cr應該要多快？

如果你并沒有處于需要專注工作的時候，那么你應該在CL被提交后盡快進行review。review回復最長的極限是一個工作日。若遵循以上指南，意味著一般的CL應該在一天內得到多輪review(如果必要的話)。

速度vs中斷

但有時候個人的速度優先度會勝過團隊速度。如果你處于需要專注工作的時候(比方說寫代碼)，不要打斷自己去做cr。

研究證實，若開發者在被打斷后會需要很長時間才能恢復到原本順暢的開發流程。因此，開發的時候，打斷自己實際上會比讓另一位開發者等待review來得更加昂貴。

取而代之的是，我們可以在投入到處理他人給的review評論之前，找個適當的時機點來進行cr。這有可能是當你的當前開發任務完成后、午餐、剛從會議脫身或從微型廚房回來等等。

快速回應

當我們談論cr的速度時，我們關注的是回應時間，而非CL需要多長時間才能完成并提交。在理想情況下，整個過程應該是快速的。

總的來說個人回應評論的速度，比起讓整個cr過程快速結束來得更為重要。即使有時需要很長時間才能完成整個流程，但若在整個過程中能快速獲得來自reviewer的回應，這將會大大減輕開發人員對于緩慢的cr過程的挫敗感。

如果真的忙到難以抽身而無法對CL進行全面review時，你依然可以快速的回應讓開發者知道你什么時候會開始審核、建議其他能夠更快回復reviewer，又或者提供一些初步的廣泛評論。(注意:這并不意味著你應該中斷開發去回復——請找到適當的中斷時間點去做)。????

很重要的是，reviewer員要花足夠的時間來進行review，確保他們給出的LGTM，意味著“此代碼符合我們的標準”。

盡管如此，理想的個人的回應速度還是越快越好。

跨時區review

在面對時區不同的問題時，盡量在他們還在辦公室時回復作者。如果他們已經回家了，那么請確保在他們第二天回到辦公室前完成。

LGTM 評論

為加快速度，在某些情況下reviewer可以給予LGTM或Approval，即便CL上仍有未解決的評論。類似情況會發生在：

• reviewer確信開發人員會適當地處理所有剩余的評論
• 剩余的評論是微不足道的或它們不需由開發者來處理
• reviewer必須清楚指明他們是指上面哪種情況

LGTM 評論對雙方處于不同的時區時尤其值得考慮，否則開發人員會等待一整天才得到“LGTM，Approval”。

大型改動

如果有人要求reivew時，但由于改動過于龐大導致你難以確定何時才有時間review它時，你通常該做的是要求開發人員將CL拆解成多個較小的CL，而不是一次review巨大的CL。這種事是可能發生的，而且對于reviewer非常有幫助，即便它需要開發人員付出額外人力來處理。

如果CL無法分解為較小的CL，且你沒有足夠時間快速查看整個CL內容時，那么至少對它的整體設計寫些評論，并發送回開發人員以便進行改進。身為reviewer，你的目標之一是在不犧牲代碼質量的狀況下，避免阻擋開發人員進度，或讓他們能夠快速采取其他更進一步的動作。

cr的能力會隨著時間進步

如果你遵循這些準則，并且對于cr非常嚴格的話，后面你會發現整個cr流程會越來越快。因為開發者學到什么是質量好的代碼，并于開頭就提交一個很棒的CL，而這正恰好只需要越來越少的時間。而reviewer則學會快速回應，而非在過程中加入不必要的延期。

但不要為提高想象中的速度，而對cr標準和代碼質量做出妥協，畢竟從長遠來看它實際上并不會讓任何事情發生得更快。

緊急狀況

在某些緊急情況下，CL會希望放寬標準以求迅速地通過整個cr過程。但請看什么是緊急情況來知道哪些情況實際上屬于緊急情況，而哪些不符合。

如何寫review評論

如何面對被推遲處理的評論

有時開發人員會推遲處理cr產生的評論。要么他們不同意你的建議，要么他們會抱怨你太嚴格了。

誰是對的

當開發人員不同意你的建議時，請先花點時間考慮一下他們是否是正確的。因為通常他們比你更了解代碼，所以他們可能真的比起你來說對代碼的某些層面具有更好的洞察力。他們的論點有意義嗎？從代碼質量的角度來看它是否合理？如果是的話，讓他們知道他們是對的，然后讓問題沉下去。

但開發人員也并不總是對的。在這種情況下，reviewer應該更進一步解釋為什么認為自己的建議是正確的。一個好的解釋通常展示了“對開發人員的回覆的理解”以及有關“為什么被要求做出改動”等信息。尤其是當reviewer認為給出的建議會改善代碼質量時，便應該繼續宣揚自己的論點。只要他們相信所需的額外的工作量最終會改善整體代碼質量。提高整體代碼質量這件事，往往是經由每個微小的改動來發生。有時往往需要幾番解釋一個建議才能讓對方真正理解你的用意。切記，始終保持禮貌，讓開發人員知道你有聽到他們在說什么，只是你不同意該論點而已。

讓開發者沮喪

reviewer有時會認為若自己堅持改進的話，會讓開發人員覺得沮喪不安。的確開發人員有時會感到很沮喪，但這通常是十分短暫的，甚至后來他們非常感謝你幫助他們提高代碼質量。一般來說，只要你在評論中表現得很有禮貌，開發人員實際上根本不會感到沮喪，這些擔憂都僅存在于reviewer心中而已。沮喪很多時候是對于cr評論的寫作方式有關，而并非來自reviewer對于代碼質量的堅持。

晚點再來整理干凈

一個常見的推遲原因是開發人員希望完成任務(這可以理解)。他們不想通過另一輪cr來批準這個CL。此時他們通常會說在以后的CL進行整理，所以你現在應該要給LGTM。當然部分開發人員非常擅長這一點，并且立即送出一個修復問題的后續CL (follow-up CL)，但根據過往經驗，這種后續“清理行為”非常少見。除非開發者在CL獲得批準之后立刻進行清理動作，否則這事根本不可能發生。這不是因為開發人員不負責任，而是因為他們可能有很多其他工作要完成，于是清理工作便會在成堆的工作中被遺忘。因此，通常最好堅持開發人員在代碼在合并后清理它們。因為讓人們「稍后清理」是致使代碼庫質量狀況下降最常見的狀況。

如果CL引入了新的復雜性的話，除非是緊急情況，否則必須在提交之前將其處理掉。如果CL導致暴露周圍的問題且現在無法解決它們的話，開發人員應該將缺陷記錄下來并分配給自己，避免后續被遺忘。又或者他們可以選擇在代碼中留下TODO的注釋并鏈接到剛記錄下的缺陷。

關于review嚴格性的常見抱怨

如果你先前以相當寬松的標準并轉趨嚴格的進行cr的話，一些開發人員會開始大聲地抱怨。一般來說，提高review的速度會讓這些抱怨逐漸消失。這些抱怨可能需要數個月才會消失，但最終開發人員會看到嚴格的review所帶來的價值，因為嚴格的review幫助他們產生的優秀代碼。而且一旦發生某些事情時，最大聲的抗議者甚至可能會成為你最堅定的支持者，因為他們會看到變得review變嚴格后所帶來的價值。

解決沖突

如果你遵循前面所有操作，但仍然遇到無法解決的雙方之間的沖突時，請參考前面的cr的標準以獲取有助于解決沖突的準則和原則。

譯者總結

cr的標準

• reviewer 有責任保證CL的質量，作為reivew的代碼的owner

• reviewer不應追求完美，而應追求持續改進

• cr具有指導意義

• 代碼風格應該與現有的一致。如果項目沒有統一風格，那就接受作者的風格

• 解決沖突難以達成共識時，需要面對面或者拉起更大的團隊討論，帶上leader

在cr中要看些什么

• CL的總體設計
• 功能驗證，功能性對于使用者們是好的，對于任何UI改動要合理且好看
• 是不是很復雜，有沒有過度設計
• 代碼有適當的單元測試
• 測試經過完善的設計
• 規范命名，看見名字就知道是什么
• 合適的注釋，注釋應該是why而不是what
• 代碼風格遵循style guide，如果需要改代碼風格應該在另一個CL解決
• CL更改了構建、測試、交互、發布的時候，也要更新文檔
• 仔細review每一行代碼(除了資源文件、生成的代碼、大型數據結構)。如果比較復雜得讓開發者解釋
• 安全性、并發性、可訪問性、國際化等復雜問題時需要更合適的人來review
• 以整個系統的角度出發來思考CL
• review的時候，與其告訴開發者做錯什么，還不如告訴他們做對了什么

如何瀏覽CL

• 用宏觀的角度來看待改動，查看CL描述以及它做什么
  
• 檢查CL主要的部分
• 用合理的順序看CL 其余的改動

review的速度

• review速度慢會導致團隊整體的速度下降、開發人員開始抗議cr、代碼質量會受到影響
• 如果你處于需要專注工作的時候(比方說寫代碼)，不要打斷自己去做cr
• 個人回應評論的速度，比起讓整個cr過程快速結束來得更為重要
• 在面對時區不同的問題時，盡量在他們還在辦公室時回復作者
• 為加快速度，在某些情況下reviewer可以給予LGTM或Approval，即便CL上仍有未解決的評論
• 由于改動過大導致難以review時，通常該做的是要求開發人員將CL拆解成多個較小的CL
• cr的速度應該要越來越快，但不要為提高想象中的速度，而對cr標準和代碼質量做出妥協

如何寫review評論

• 當開發人員不同意你的建議時，思考一下誰是正確的，并解釋清楚，保持禮貌
• 如果review堅持己見，會讓開發者沮喪。沮喪很多時候是對于cr評論的寫作方式有關，并非來自reviewer對于代碼質量的堅持
• 如果CL引入了新的問題的話，除非是緊急情況，否則必須在提交之前將其處理掉
• 如果現在無法解決review的評論的問題的話，TODO的注釋并鏈接到剛記錄下的缺陷

review太嚴格被抱怨該怎么辦

• 提高review的速度會讓這些抱怨逐漸消失。這些抱怨可能需要數個月才消失，但最終開發人員會看到嚴格的review所帶來的價值，因為嚴格的review幫助他們產生的優秀代碼

總結

以上是生活随笔為你收集整理的Google: 如何做code review？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。