Google的代碼之所以優秀原因其實很簡單：他們非常重視代碼審查。代碼審查並不是Google獨有的，它被公認爲是一個很好的（提高代碼質量的）手段，很多人已經在日常開發中採用代碼審查。但我還沒有看到哪一家大公司（像谷歌這樣）應用得如此廣泛。在谷歌，任何的產品或者項目代碼在檢入（代碼倉庫）之前都需要進行有效的審查。
每個人都要參與代碼審查，而且這裏我指的不是非正式的審查：它是軟件開發環節中非常重要而且通用的規則。不僅是產品代碼，所有的代碼都需要進行審查。審查代碼不需要投入很多的精力，但是（與不做審查相比）產生的效果卻是天壤之別。
關於代碼審查（code review），Jonathan Danylko 的看法是“代碼要經常檢查（包括自查和其他同事檢查）。不要把別人的檢查，看成是對代碼風格的苛求。應該把它們看作是有建設性的批評。對個人來說，經常檢查你的代碼並且自問，“我怎樣才能寫得更好呢？”
這會加速你的成長，讓你成爲一個更優秀的程序員。”
你能從代碼審查中收穫什麼？
事實顯而易見，有另外一個人檢查即將提交的代碼，能夠幫助找到bug。這是代碼審查衆所周知且經常被提及的好處。但依據我的經驗，這是最沒有價值的一個好處。人們確實可以在代碼審查中找到bug。然而坦率地說，在代碼審查中找到的bug絕大多數都是一些代碼作者花上幾分鐘就能找到的小bug。那些真正 需要花時間才能找到的bug在代碼審查中是檢查不到的。
代碼審查最大的好處在於它是一種社交的途徑。如果你編程的時候就知道會有同事檢查你的代碼，那麼你的程序會有所不同。你寫的代 碼會更加整潔，有着較好的註釋，結構也組織的不錯——因爲你知道會有人來檢查你的代碼，而且你很在意他們的意見。如果沒有代碼審查，你知道代碼會在最後才 會審查。因爲不是馬上就要檢查，所以對你而言並不緊迫，因而你不會想着先自檢一遍。
代碼審查還有一個更大的好處，就是可以分享知識。在很多的開發團隊中，每個人都會負責並且專注於一個核心模塊。除非別的同事負 責的模塊出現問題導致自己的代碼不能運行，否則他們是不會去關注別人的工作。這樣產生的結果是，每一個模塊的代碼只有一個人比較熟悉。假如事不湊巧，那位 程序員正好休假或者離開了公司，那麼沒有人瞭解那些代碼了。如果有代碼審查的環節，那麼至少會有兩個人熟悉代碼——代碼的作者和審閱者。審閱者雖然沒有作 者對代碼那麼瞭解——但是他同樣熟悉代碼的設計和結構，這些信息是無價之寶。
當然，沒有什麼事情是那麼簡單的。以我的的經驗看來，要做好代碼審查需要一段時間練習。我注意到經驗不足的審閱者通常會落入一些代碼審查的陷阱，這些 陷阱往往會造成很多的麻煩，給那些希望嘗試代碼審查的人們留下了壞印象，成爲了他們採納代碼審查的一個主要障礙。
代碼審查最重要規則是對即將提交的代碼中查找問題——你需要做的就是確認代碼是正確的。而通常會犯的一個錯誤，也是剛剛接觸代碼審查的新手容易犯的一個錯誤，即審閱者會判斷這段代碼是否按照自己思路來實現（誤區一）。
當有一個問題需要解決時，通常會有幾十種的辦法。當選定一個解決方法時，會有百萬種代碼實現。因此，作爲一個審閱者，你的工作不是確保代碼是按照你的方式來編寫的——因爲這是不可能的事情。審閱者的工作是確保原作者編寫的代碼是正確的。如果你沒有遵守這個規則，你可能會到處碰壁，審查結束時你的心情很 糟糕，對你來說肯定不是一件好事情。
問題在於這是不自覺就會犯的一個錯誤。假定你是一個程序員，當你在看一個問題的時候，你會得到一個自己的解決方案——並且你認爲你看到的就是這個問題（應該採用的）解決辦法。如果想要成爲一名好的審查者，你需要知道這是不對的。
第二個誤區就是人們感覺一定要說點什麼（纔算是做了代碼審查）。代碼的作者花了很多的時間和精力來編寫代碼——你難道不應該說點什麼嗎？
答案是：你不應該。
如果只是說“哦，這看起來這不錯！”，這永遠沒錯。反之，如果你不斷地去查找一些“問題”並加以指責，那麼我肯定你的信譽會蕩然無存。如果你不斷地去製造一些事情來說些什麼，那麼代碼的作者會認爲，當你的言論只是爲了避免冷場。從此，你的意見不會受到重視。
第三個誤區就是速度。你不應該匆忙完成一次代碼審查——但是也不要拖延。你的同事在那裏等着你的審查結果。如果你和同事不願意 抽出時間來做代碼審查或者一直拖延，大家會對這次的審查感到厭煩，也會認爲以後的代碼審查也只會帶來麻煩。看起來好像代碼審查會打斷你的工作，其實不必如 此。你不必要在別人要求你審查的時候馬上丟掉手頭上的事情。但是在幾個小時之內，當你工作中間休息的時候——喝杯茶，去一下洗手間或者聊聊天，散散步。當 你再回來工作的時候，你可以開始並完成這個代碼審查。如果你這麼做了，沒有人會站在你身邊一直等着你給出審查結果。
