【轉】Google 官方文章——如何去做code review

Google 前幾天公開了一篇谷歌的工程實踐文檔。而且文檔的內容都是跟 code review 相關的內容，裏面包含了 Google 工程師如何進行 code review 的內容，以及 code review 指南。原文地址: google.github.io/eng-practic…

本文的名詞解釋：

cr: code review
cl: change list，指這次改動
reviewer: cr的那個review人
nit: 全稱nitpick，意思是雞蛋裏挑骨頭
作者: 也就是本次CL的開發者，原文中是以author來稱開發者的。以老外的思維，意思是“CL的作者”

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是爲了處理某個緊急事情而存在。

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

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

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

命名

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

註釋

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

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

查看該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的其他較小部分提供適當上下文，而且這樣通常可以提高review速度。如果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幫助他們產生的優秀代碼。