著重品質及效率的軟體開發團隊一定會做 code review，因為它是開發流程裡唯一讓開發人員有機會針對代碼進行深入討論的關鍵活動。

因爲不同的團隊會用不同的方式執行 code review，並沒有一套固定的方法可以適用所有情況，所以我試著根據過去的經驗，整理我心中認為理想的 code review 運作方式。

要用什麼工具？

我認為使用 code review system 這類的工具是必須的，否則管理版本修改 (patches) 或是追蹤 reviewer 給的建議 (comments) 就會太過費力，反而削減了 code review 帶來的好處。

免費的選擇我會推薦 Gerrit 或是 Phabricator ，架設其實都蠻簡單的。

Gerrit 的使用建議可以參考：

Review 那些東西？

以下是我認為除了 bug 以外需要檢查的部分，依照重要程度列舉如下：

  1. 符合原始架構設計
  2. API 設計
  3. 易讀性及可維護性
  4. 安全性
  5. 代碼風格

有幾個原則可以遵循：

  • 團隊應該有一致的代碼標準 (coding standards)，這樣比較不會有爭議。
  • 盡量使用代碼檢查工具 (static analysis) 來代替人工的檢查。
  • 善用 astyle 或是 uncrustify 這類的 code formatting 工具來維持代碼風格的一致性。

如何有效溝通？

  • Commit message 很重要，好的 commit message 可以讓 review 快速理解為什麼這個改動是必要的。
  • Review 的改動不應該太大，一次改個上千行是很難仔細檢查的，所以 reviewer 有權利退回太大的改動。

Ask a programmer to review 10 lines of code, he’ll find 10 issues. Ask him to do 500 lines and he’ll say it looks good".

— The harsh truth about code reviews.

如何加快 review?

  • Review 的建議可以大致分成兩類：
    • must fix: 一定要修正的問題。
    • nice to have: 建議要修正的問題，但如果需要花太多時間來修改，可以另外開 task 來追蹤。
  • 如果 must fix 類的問題都處理了，reviewer 應該就要 ＋2 放行了。
  • nice to have 的問題則是以互相信任尊重的態度來處理。
  • Reviewer 如果拖延太久沒有開始 review，作者應該主動提醒。

正確的心態

  • 把代碼寫好是作者的責任，reviewer 有責任把關，但不應該要求 reviewer 要抓出所有的 bug。
  • reviewer 不一定能完全了解實作的細節，所以給的建議不見得是完全正確的，作者不應盲目遵守而是要有自己的判斷。

參考