code review到底在審查什麼？
在做一個代碼的code review時，以下是我們需要關注的：
是否明晰
-
代碼應該易於閱讀，應該一目瞭然地瞭解每行和每個功能，否則，它太複雜了。
-
代碼應符合模塊內已使用的編碼風格（縮進，間距，命名約定等）
-
每個函數或方法的預期意圖都應簡潔明瞭，並且一個函數不能超出一屏（幾十行代碼）。否則，它太複雜了。
-
代碼是否適當地增加了註釋，以供他人理解和維護？
註釋是否簡潔，易於理解，並且實際上爲周圍的代碼增加了價值？
每個函數的意圖是否明確，或者增加描述意圖的最小注釋是否會有所幫助？
API是否用Javadoc（Java）記錄？
解釋爲什麼和解釋是什麼一樣重要，記錄意圖是最重要的記錄形式，因爲沒有人知道你在想什麼。
- 是否使用了不必要的和/或晦澀的語言技巧，即使僅僅30秒也可能使讀者感到困惑？
- 每個函數是否橋接一個抽象級別，調用較低級別的函數？
- 是否存在跨越數十行的“函數”功能，這些功能可以輕鬆拆分爲子函數？
- 代碼被註釋掉了嗎？在極少數情況下，這是適當的。一般來說，註釋掉的代碼使閱讀起來更困難，也很難理解-不要以爲每個人都在使用語法突出顯示。
正確性
- 有明顯的錯誤嗎？
- 有單元測試並且已經運行了嗎？
- 單元測試是否足以測試代碼（或代碼的更改）？是否有代碼覆蓋工具會自動與構建一起運行？
- 是否是線程安全的？是否在類或API級別記錄了線程安全性和併發性，以便調用者理解預期的語義？
設計意義
- 設計是否有意義（更改或不更改）？
- 更改是否適合現有設計（例如，新職責是否屬於更改後的實體）？
- 所做的更改是否揭示了現有設計中的缺陷（例如，簡單的行爲更改需要複雜的代碼更改）？
- 此更改是否完全解決了所有功能/問題的要求？需求的解釋方式可能導致生產中的問題是否存在歧義？
重用和重複代碼
- 包內的代碼是否重複？如果在模塊中甚至幾行代碼被重複複製了多次，則表明需要重構。
- 共享庫中應該有局部函數嗎？
- 是否存在可以完全刪除或替換爲現有庫的代碼？
配置和常量
- 是否在整個代碼中散佈了魔術數字或字符串常量，或更糟糕的是，重複多個地方使用這些常量？
- 是否有所有配置都設置了默認值？
- 配置文件是否增加了清晰的配置說明？
向後兼容和版本控制
- 該代碼向後兼容其預先存在的API嗎？
- 代碼向後兼容其預先存在的配置嗎？
- 是否存在並非必需的向後不兼容的更改？
- 如果存在向後不兼容的更改，將如何在軟件包構建和部署方面進行管理？
依存關係
- 是否引入了新的外部依賴關係，是否會帶來新的可用性或操作風險？
- 是否確實需要每個新庫依賴項？是否每個現有依賴項都絕對必要？您能以更簡單的方式解決問題嗎？不要僅僅將最新和最出色的組件視爲依賴項，因爲您認爲它們是浮華的。
- 是否有替代的“較輕量”依賴項可以替代使用？
故障處理
-
該代碼可處理任何庫代碼調用返回的意外值？
-
代碼對非法輸入和空輸入怎麼處理？
-
該代碼是否處理了邊緣case？
-
代碼是否有清晰一致的異常處理策略？
性能
- 是否有過早優化的跡象？
- 有沒有明顯的性能或效率問題可以解決？
- 如果大部分額外的時間都花在了代碼阻塞上，代碼執行時間也會更長嗎？
性能指標metrics
- 該指標是否有助於運營活動？
- 是否容易知道已部署的代碼在做什麼？
- 從錯誤到調試的所有級別都有適當數量的日誌記錄嗎？
- 代碼中是否收集了性能指標？
- 每個日誌消息是否都包含足夠的相關信息，以便某人僅閱讀日誌消息就能瞭解系統的行爲？
- 測試中是否包裝了複雜的info / debug / verbose日誌語句if (log level)，以免影響性能？
SQL
- 用戶輸入是否用於構建原始SQL？（請參閱SQL注入）
- 在檢查之前是否已計劃好所有SQL查詢的解釋？
- 是否在每個SQL語句上方以註釋的形式簽入瞭解釋計劃結果，作爲開發人員期望查詢執行的快照？在比較未來的解釋計劃以檢查假設是否發生變化時，這可能非常有用。
- 是否正確使用了綁定變量，或者生成了一個關閉的SQL語句？
- 此更改是否需要回填或直接數據庫更新，並且是否已審查了回填腳本？