Google 的 Code Review 文化

來聊聊 Google 的 code review 文化。

在 Google，要 submit 一個 CL (changelist, 等同於 git 裡的 pull request)，需要經過三關的 code review：1. 自動化程式 review, 2. team/project review, 3. readability review。第一關，由程式或 AI 就能針對不同面向，自動從 CL 裡面挑出一些顯而易見的錯誤，或是可以改善的地方。第二關，就好理解多了，主要是由 team members 去針對功能上部分做檢查。第三關，會依照 CL 裡面用到的語言，而需要請該語言的大神們來 review (由系統自動指定)，針對程式語法上可以改進的部分，給予建議。基本上這是蠻好的機制，強制大家都遵守同一套 coding style，以及套用一些像是 Effective Java 或是 Effective Dart 之類的 best practice。總之，就是無所不用其極地，避免各種髒 code 進到全公司共用的 monorepo 當中。同時，在神人們的指教當中，自己也能從中學到許多實用的技巧。

然而，這不是沒有代價的。這樣嚴格的把關，尤其是 readability review，勢必會大幅拖累開發的速度。有時候，當 reviewer 是其他時區的人，如果不巧對方又是個大忙人，一來一往可能幾天甚至一個多禮拜就過去了。再者，有些 reviewer 的標準之高，到了一種近乎苛求毫無道理的地步。舉例來說，常會有 reviewer 要求所有變數、函式都要寫 comment，即使變數名稱或函式名稱本身已經很清楚地說明了它的用途，於是就配合寫上跟變數名稱或函式名稱很像的 comment，然後又會被要求要多補充一些額外的資訊，不然乾脆不要寫，於是就得硬著頭皮再去扯一些可有可無的東西硬塞到 comment 裡。而 comment 的用字遣詞又暗藏了許多潛規則，像是 boolean 變數的 comment 一定要用 "Whether" 開頭、函式 comment 一定要以第三人稱單數的動詞開頭之類的，繁族不及備載。另外，有時還會遇到不同 reviewers 持相反意見的情況。而有時也會遇到 reviewer 對於選用的 solution 發表意見，早已超越了 readability 該審核的範圍，你如果不照他的建議調整他還不太高興，把你的 readability 分數扣分 (readability 分數是用來晉升到大神的主要參考依據。像我們這種初階平民，如果未來想要晉升大神去幫別人 review code，就要透過不斷 submit code，以獲得足夠多的大神們的分數累積後，才得以晉升)。不誇張地說，整個開發時程，大約只有 1/3 在寫主體，另外 1/3 在寫 test cases，還有 1/3 在搞 code review，而後兩者往往還會佔掉更多比例。

總之，這是一套有利有弊的機制，整體來說絕對是利大於弊，畢竟這麼大的公司，這麼多複雜的系統，實在容不下一點點的污點。這個世界上，能把 code review 做到這種地步，全公司上下都對程式品質苛求到一種變態的程度的，大概也只有 Google 了吧。