Google 的 Code Review 目標是不斷提供 codebase 的質量，同時要求審閱者在代碼的高質量和業務的推進之間做好權衡，兩邊的極端都不要走，並給出了一些 實戰經驗 ，下面我總結了下：

1. 設計

新增的幾塊代碼是否有意義？代碼的結構是否合理，應該放在 codebase 裏還是抽離成組件？對系統的持續集成是否會造成印象？等等

2. 功能

站在用戶的角度和開發者的角度，從功能和代碼塊上去審閱功能的合理性，除此之外，還要考慮單從代碼上看不到的問題，比如併發問題、UI 交互問題、死鎖問題等等。

3. 複雜度

審查是否存在工程上的過度設計，鼓勵解決當下的問題，不要對未來做過多的設計，因爲未來（業務）充滿了不確定性。

4. 測試

除非是緊急上線，一般情況下，都要求提交的代碼有單元測試、集成測試和端對端測試，要確保測試用例正確、有意義、有效果。

5. 命名

開發者是否給所有的變量都準確命名？一個好的命名不應太長也不可過短，剛好讓人看懂最好了。

6. 評論

開發者寫的評論除了他自己別人看得懂麼？所有的評論是否是有意義的？是否描述清楚了代碼是幹啥的？有一點需要強調：對於正則以及複雜的邏輯是必須加註釋的。

7. 格式

這一塊我覺得他講的並不好，格式主要在工具層面通過 lint 來糾正，只不過格式之外會有一些團隊的約定，需要人爲去判斷或者不好工具檢測的部分，可以在 Code Review 的時候提出來。

8. 文檔

相關的 README 或者文檔自動生成工具是否補全，廢棄的代碼、文檔是否刪除等。

9. 每一行

確保每一行都仔細審閱，包括數據文件、自動生成的文件、大的數據結構描述等等，如果代碼很難閱讀，你應該提前告訴開發者注意這方面的問題，難閱讀的代碼，對任何人都是一樣難閱讀的，這種代碼應該儘量避免出現。

10. 上下文

Code Review 工具一般只會展示 diff 的內容，有的時候，你需要閱讀整個文件，以確保開發者的邏輯是有用的，站在系統層面去考慮，這段代碼是否會帶來複雜度，是否是健康的。

11. 好的內容

如果你看到開發者寫的內容不錯，不要吝嗇的讚美和鼓勵。

相關文章