好文分享 —— Google 如何做到 97% 高滿意度的 Code Reviews
“How Google takes the pain out of code reviews, with 97% dev satisfaction” 1 文揭露 Google 內部的 Code Review 工具以及他們大致的 Code Review Guidelines 。
有 5 點值得學習：
- 持續改善勝過追求完美
Google 鼓勵持續改善勝過追求完美，主要是若過於追求完美，可能導致 Code Review 的過程變得艱難，將導致開發者未來不願意對程式碼做出改善。這個相當合理，如果初衷是好的，但是卻要面對排山倒海般的質疑、要求，才能將程式碼推上 production 的話，將會導致寒蟬效應，對其他人造成嚇阻作用，大家寧可不動就不動。
- 鼓勵分享、散播知識
好的 Code Review 能夠透過分享/教學的過程，提升團隊成員彼此的開發能力與素養，增進彼此對於 Codebase 的認識。幫助彼此提升的好處在於如果未來有任何重大事故，隨時都可以有人站出來接手，不會讓特定團隊成員成為整個專案或某個功能的 Single Point of Failure 。
- 保持專業與禮貌
看來 Google 也有遇到同理心的問題，所以希望 Reviewer 必須保持專業與禮貌，而且必須對 PR 作者的解決方案保持開放的態度，只有必要的時候才需要提出替代方案。不過，我對這點較不贊同，應該還是要提供替代方案比較好，因為有時候可能是 PR 作者沒想到，所以提出替代方案讓 PR 作者衡量也是不錯的作法，至於 PR 作者要不要採用就交由其決定。
- 做出足夠小的變更
Google 覺得變更最好在 200 行左右就好，不過此限制其實沒有標準答案，畢竟以 Google 的產品量級與追求穩定性的需求， PR 越小的話，如果有任何事故發生，越容易找到問題，也會越容易確定受災範圍。
- 追求可讀性(readability)
Google 規定 PR 還要有額外 Readability approvals 才能通過 Code Review 。追求可讀性，我個人超級認同，畢竟程式碼是給人看的，而人的程度有高低之分，所以越容易理解的程式碼，越能夠讓人容易修改、維護，難以閱讀的程式不僅容易墊高進入門檻，也容易讓他人不願意著手修改、維護，這就是為什麼經常有人接手 1 個系統之後都會喊著要重寫的原因，問題可能出在可讀性⋯⋯（不過再下一個接手也通常會喊相同的事⋯⋯）。
除了上述 5 點之外，其實讓 Google 的 Code Review 流程有高滿意的原因在於它的內部工具 “Critique” 體驗太好，可以想像是 Google 內部在用的 GitHub, 不僅內建 Coding Style 檢查、更強大的 diff 工具、交互引用(cross-references)、靜態分析等等，而且還能夠給 “Critique” 回饋(feedback)，讓它有進化的機會，好用到連已經離職的 Googlers 還會在 Reddit 發文懷念這個工具ＸＤ
不過 “Critique” 畢竟是內部使用的工具，一般人也無法體會，所以該文最後提供大家可以使用 “Gerrit” 這套同樣由 Google 所維護的開源工具，該工具功能與 “Critique” 有著類似的功能，有興趣的朋友可以試看看。
“How Google takes the pain out of code reviews, with 97% dev satisfaction” 1 文的最後，有附上 4 篇 Google 關於 Code Review 的文獻可以參考，想了解更多的話，歡迎閱讀原文。 #原文連結在留言
How Google takes the pain out of code reviews, with 97% dev satisfaction
