Google是如何做程式碼審查的？

Google是一個非常優秀的公司。他們做出了很多令人稱讚的東西—既是公司外部，人們可以看到的東西，也是公司內部。有一些在公司內部並不屬於保密的事情，在外部並沒有給予足夠廣泛的討論。這就是我今天要說的。

讓Google的程式如此優秀的一個最重要的事情看起來是非常的簡單：程式碼審查。並不是只有Google做這個事情—程式碼審查已經被廣泛的認可為一種非常好的做法，很多人都在這樣做。但我還沒有看到第二家這樣大的公司能把這種事情運用的如此普遍。在Google，沒有程式，任何產品、任何專案的程式程式碼，可以在沒有經過有效的程式碼審查前提交到程式碼庫裡的。

所有人都要經過程式碼審查。並且很正規的：這種事情應該成為任何重要的軟體開發工作中一個基本制度。並不單指產品程式——所有東西。它不需要很多的工作，但它的效果是巨大的。

從程式碼審查裡能得到什麼？

很顯然：在程式碼提交前，用第二群眼睛檢查一遍，防止bug混入。這是對其最常見的理解，是對程式碼審查的好處的最廣泛的認識。但是，依我的經驗來看，這反倒是它最不重要的一點。人們確實在程式碼審查中找到了bug。可是，這些在程式碼審查中能發現的絕大部分bug，很顯然，都是微不足道的bug，程式的作者花幾分鐘的時間就能發現它們。真正需要花時間去發現的bug不是在程式碼審查裡能找到的。

程式碼審查的最大的功用是純社會性的。如果你在程式設計，而且知道將會有同事檢查你的程式碼，你程式設計態度就完全不一樣了。你寫出的程式碼將更加整潔，有更好的註釋，更好的程式結構——因為你知道，那個你很在意的人將會檢視你的程式。沒有程式碼審查，你知道人們最終還是會看你的程式。但這種事情不是立即發生的事，它不會給你帶來同等的緊迫感，它不會給你相同的個人評判的那種感受。

還有一個非常重要的好處。程式碼審查能傳播知識。在很多的開發團隊裡，經常每一個人負責一個核心模組，每個人都只關注他自己的那個模組。除非是同事的模組影響了自己的程式，他們從不相互交流。這種情況的後果是，每個模組只有一個人熟悉裡面的程式碼。如果這個人休假或——但願不是——辭職了，其他人則束手無策。通過程式碼審查，至少會有兩個人熟悉這些程式——作者，以及審查者。審查者並不能像程式的作者一樣對程式十分了解——但他會熟悉程式的設計和架構，這是極其重要的。

當然，沒有什麼事情能簡單的做下來的。依我的經驗，在你能正確的進行程式碼審查前，你需要花時間鍛鍊學習。我發現人們在程式碼審查時經常會犯一些錯誤，導致不少麻煩——尤其在一些缺乏經驗的審查者中經常的出現，他們給了人們一個很遭的程式碼審查的體驗，成為了人們接受程式碼審查制度的一個障礙。

最重要的一個原則：程式碼審查用意是在程式碼提交前找到其中的問題——你要發現是它的正確。在程式碼審查中最常犯的錯誤——幾乎每個新手都會犯的錯誤——是，審查者根據自己的程式設計習慣來評判別人的程式碼。

對於一個問題，通常我們能找出十幾種方法去解決。對於一種解決方案，我們能有百萬種編碼方案來實現它。作為一個審查者，你的任務不是來確保被審查的程式碼都採用的是你的編碼風格——因為它不可能跟你寫的一樣。作為一段程式碼的審查者的任務是確保由作者自己寫出的程式碼是正確的。一旦這個原則被打破，你最終將會倍感折磨，深受挫折——這可不是我們想要的結果。

問題在於，這種錯誤是如此的普遍而易犯。如果你是個程式設計師，當你遇到一個問題，你能想到一種解決方案——你就把你想到的方案作為標準答案。但事情不是這樣的——作為一個好的審查者，你需要明白這個道理。

程式碼審查的第二個易犯的毛病是，人們覺得有壓力，感覺非要說點什麼才好。你知道作者用了大量的時間和精力來實現這些程式——不該說點什麼嗎？

不，你不需要。

只說一句“哇，不錯呀”，任何時候都不會不合適。如果你總是力圖找出一點什麼東西來批評，你這樣做的結果只會損害自己的威望。當你不厭其煩的找出一些東西來，只是為了說些什麼，被審查人就會知道，你說這些話只是為了填補寂靜。你的評論將不再被人重視。

第三是速度。你不能匆匆忙忙的進行一次程式碼審查——但你也要能迅速的完成。你的同伴在等你。如果你和你的同事並不想花太多時間進行程式碼複查，你們很快的完成，那被審查者會覺得很沮喪，這種程式碼審查帶來的只有失望的感覺。就好象是打攪了大家，使大家放下手頭的工作來進行審查。事情不該是這樣。你並不需要推掉手頭上的任何事情來做程式碼審查。但如果中途耽誤了幾個小時，你中間還要休息一會，喝杯茶，衝個澡，或談會兒閒話。當你回到審查現場，你可以繼續下去，把事情做完。如果你真是這樣，我想沒有人願意在那乾等著你。

原文出處： Mark CC
譯文出處：外刊IT評論