在代碼審查中尋找什麼
注意：在考慮以上各點時，請務必確保考慮 《代碼審查標準》。
設計
審查中最重要的內容是CL的總體設計。CL中各個代碼段的交互是否有意義？此更改是屬於您的代碼庫還是屬於庫？它是否與您的系統的其餘部分很好地集成？現在是添加此功能的好時機嗎？
功能性
此CL是否達到開發人員的預期目的？開發人員打算爲該代碼的用戶帶來什麼好處？“用戶”通常既是最終用戶（當他們受到變更影響時）又是開發人員（將來他們將不得不“使用”此代碼）。
通常，我們希望開發人員能夠對CL進行充分的測試，以確保它們在進行代碼審查時能夠正常工作。但是，作爲審閱者，您仍然應該考慮邊緣情況，尋找併發問題，嘗試像用戶一樣思考，並確保沒有任何錯誤，只是閱讀代碼即可看到。
您可以根據需要驗證CL，對於審閱者而言，檢查CL的行爲最重要的時間是對用戶產生影響（例如 UI更改）。當您僅閱讀代碼時，很難理解某些更改將如何影響用戶。對於這樣的更改，如果過於麻煩而無法在CL中打補丁並自己嘗試，則可以讓開發人員爲您提供功能演示。
另一個時候在代碼審查期間考慮功能性尤其重要的是，CL中是否正在進行某種併發編程，從理論上講可能會導致死鎖或競爭條件。僅通過運行代碼很難檢測到這類問題，通常需要有人（開發人員和審閱者）仔細考慮它們，以確保不會引入問題。（請注意，這也是在可能出現競爭條件或死鎖的地方不使用併發模型的一個很好的理由，這會使進行代碼審查或理解代碼非常複雜。）
複雜
CL是否比應該的要複雜？在CL的每個級別都進行檢查-個別行是否太複雜？功能太複雜了嗎？類太複雜了嗎？“太複雜”通常意味着“代碼閱讀器無法快速理解。” 這也可能意味着“開發人員在嘗試調用或修改此代碼時可能會引入錯誤。”
複雜性的一種特殊類型是過度設計，即開發人員使代碼變得比需要的通用，或者增加了系統目前不需要的功能。評論者應特別警惕過度設計。鼓勵開發人員解決他們現在知道需要解決的問題，而不是解決開發人員推測 將來可能需要解決的問題。未來的問題一到達就應該解決，您可以在物理宇宙中看到它的實際形狀和要求。
測試
根據更改要求進行單元測試，集成測試或端到端測試。通常，除非CL處理緊急情況，否則應在與生產代碼相同的CL中添加測試 。
確保CL中的測試正確，合理且有用。測試不會自我測試，我們很少爲測試編寫測試-人員必須確保測試有效。
代碼破損時，測試實際上會失敗嗎？如果代碼在其下面更改，它們將開始產生誤報嗎？每個測試都會做出簡單而有用的斷言嗎？測試是否在不同的測試方法之間適當分開？
請記住，測試也是必須維護的代碼。不要僅僅因爲它們不是主要二進制文件的一部分而接受測試中的複雜性。
命名
開發人員是否爲所有事情都選擇了好名字？一個好名字足夠長，可以充分傳達物品的含義或作用，而又不會太長而難以閱讀。
註釋
開發人員是否用易於理解的英語寫下清晰的評論？所有評論實際上都是必要的嗎？通常，當註釋解釋了爲什麼存在某些代碼並且不應該解釋某些代碼在做什麼時，它們很有用。如果代碼不夠清晰，無法解釋自身，則應使代碼更簡單。有一些例外情況（例如，正則表達式和複雜算法通常會從註釋中解釋它們的作用，從而大大受益），但大多數註釋是針對代碼本身可能無法包含的信息，例如決策背後的原因。
查看此CL之前的註釋也可能會有所幫助。也許有一個待辦事項現在可以刪除，有意見建議不要做此更改，等等。
請注意，註釋與類，模塊或函數的文檔不同，註釋應代之以表達一段代碼的目的，應如何使用代碼以及代碼在使用時的行爲。
樣式
我們風格指南在谷歌爲我們所有的主要語言，甚至對於大多數小語種的。確保CL遵循適當的樣式指南。
如果您想改善樣式指南中沒有的樣式點，請在註釋前面加上“ Nit：”，以使開發人員知道這是您認爲可以改善代碼但不是強制性的選擇。不要阻止僅根據個人風格偏好提交CL。
CL的作者不應將主要樣式更改與其他更改結合在一起。這使得很難看到CL中的更改，使合併和回滾更加複雜，並導致其他問題。例如，如果作者想要重新格式化整個文件，請他們將重新格式化的文件作爲一個CL發送給您，然後再發送另一個CL及其功能更改。
一致性
如果現有代碼與樣式指南不一致怎麼辦？根據我們的 代碼審查原則，樣式指南是絕對的權力：如果樣式指南需要某些內容，則CL應遵循準則。
否則，如果樣式指南只是一個建議而不是一個要求，那麼就需要判斷新代碼是否應與樣式指南或周圍的代碼保持一致。除非當地不一致會造成混亂，否則請遵循樣式指南。
如果沒有其他規則適用，則作者應保持與現有代碼的一致性。
無論哪種方式，都鼓勵作者提交一個錯誤並添加一個TODO來清理現有代碼。
文獻資料
如果CL改變了用戶構建，測試，與代碼交互或發佈代碼的方式，請檢查它是否還更新了相關文檔，包括自述文件，g3doc頁面和任何生成的參考文檔。如果CL刪除或不贊成使用代碼，請考慮是否還應刪除該文檔。如果缺少文檔，請提出要求。
每一行代碼
查看分配給您檢查的每一行代碼。有時可以掃描某些數據文件，生成的代碼或大型數據結構之類的東西，但不要掃描人工編寫的類，函數或代碼塊，並認爲其中的內容是可以的。顯然，某些代碼比其他代碼更需要仔細檢查-這是您必須做出的判斷調用-但您至少應確保您瞭解所有代碼在做什麼。
如果對您來說太難閱讀代碼了，這會使審查速度變慢，那麼您應該讓開發人員知道這一點，並等待他們澄清，然後再嘗試審查。在Google，我們聘請了出色的軟件工程師，您就是其中之一。如果您聽不懂代碼，其他開發人員也很可能不會。因此，當您要求開發人員進行澄清時，您還可以幫助將來的開發人員理解此代碼。
如果您瞭解代碼，但不具備執行部分審覈的資格，請確保在CL上有一位合格的審覈者，尤其是在複雜性問題（例如安全性，併發性，可訪問性，國際化等）上。
語境
在廣泛的背景下查看CL通常會很有幫助。通常，代碼查看工具只會向您顯示圍繞要更改的部分的幾行代碼。有時，您必須查看整個文件，以確保更改確實有意義。例如，您可能會看到僅添加了四行，但是當您查看整個文件時，您會發現這四行位於50行方法中，現在確實需要分解爲較小的方法。
在整個系統的上下文中考慮CL也很有用。該CL是在改善系統的代碼運行狀況，還是使整個系統更加複雜，測試更少等？不要接受會降低系統代碼運行狀況的CL。大多數系統都會通過許多小的變化而變得複雜，因此，重要的是要防止新變化中出現很小的複雜性。
好代碼
如果您在CL中看到不錯的東西，請告訴開發人員，尤其是當他們以出色的方式回答了您的評論之一時。代碼審查通常只關注錯誤，但是他們也應該鼓勵和讚賞良好實踐。在指導方面，有時候告訴開發人員正確的做法比告訴他們錯誤的做法更有價值。
摘要
在進行代碼審查時，您應確保：
- 代碼經過精心設計。
- 該功能對代碼的用戶來說很好。
- UI的任何更改都是明智的，並且看起來不錯。
- 任何並行編程都是安全完成的。
- 代碼沒有比需要的複雜。
- 開發人員沒有實現他們將來可能需要的東西，但是不知道他們現在需要什麼。
- 代碼具有適當的單元測試。
- 測試經過精心設計。
- 開發人員對所有內容都使用了清晰的名稱。
- 註釋清晰而有用，並且大多數解釋了原因而不是原因。
- 代碼已適當記錄（通常在g3doc中）。
- 該代碼符合我們的樣式指南。
確保檢查要求檢查的每一行代碼，查看上下文，確保改善代碼的運行狀況，並稱贊開發人員所做的出色工作。
參考
https://google.github.io/eng-practices/review/reviewer/looking-for.html