在上一篇博客里我暗示自己將不在為Google工作。 我還沒有決定好去哪兒-有幾個非常不錯的工作機會讓我選擇。鑒於這段時間內我不受雇於任何公司，我想我可以寫點和專業相關的東西，這些東西很有趣，但是如果我還在職，可能會導致與同事/老板的關系緊張。
Google是一個相當酷的公司。它們完成了一些非常讓人吃驚的事情-包括外部用戶可以看到的，也包括公司內的。有些關於公司內部的東西是非保密性的，但是在公司外部討論的並不廣泛，這些就是我想說的。
保證Google的代碼質量如此之好的最大原因是代碼審查。這不是Google專有的-這是被廣為接受的好主意，而且很多人都在做。但是我從來沒有見過另外一個大公司會應用的這么普遍，在Google,任何產品/項目的代碼只有得到正面的審查才可以提交。
每個人都應該這么做，我不是指非正式的:這是一個嚴格的軟件開發過程必備的普遍規則，其范圍不只包括產品代碼而是所有的代碼。這並不需要做很多工作，但是產生的效果非常大。
你可以從代碼審查里得到什么呢？
有一點很明顯，在代碼提交之前如果有很多雙眼睛盯着看可以發現Bug.這是代碼審查最廣為人知的好處，但是以我的經驗看這是價值最小的一點。人們的確可以在代碼審查中發現Bug,但是這些Bug大部分都是顯而易見的小Bug,開發者分分鍾就可以發現，而那些真正需要花時間發現的Bug通常不是在代碼審查中發現的。
代碼審核最大的好處是純社會性的。如果你編程的時候知道你的同事將要看你的代碼，你的編程方式會不一樣。你的代碼會寫的更整潔，注釋更清楚，組織的更好-因為你知道其他人會看你的代碼，他們的意見是你需要你關注的。如果沒有審查，你雖然知道人們最后會去看你的代碼，但是那樣不會給你一種緊迫感，也不會給你同樣的個人評判的感覺。
還有一個更大的好處就是代碼審查可以傳播知識。在很多的開發小組里，每個人都負責某一塊核心組件，專注於自己的這一塊，只要其他同事的模塊不會破壞自己的代碼就不會去關注。這種模式導致一個模塊只有一個人熟悉對應的代碼。如果一個人請假或離職，其他人對他負責的模塊將一無所知。如果采用代碼審核，那么至少有兩個人熟悉代碼-作者和審查者。審查者知道的代碼不如作者多，但是他們都熟悉代碼的設計和結構，這意義重大。
當然，沒有什么事情會這么簡單的，以我的經驗，你需要花一些時間來做好代碼審查。我已經見過一些坑導致的問題-由於他們在經驗不足的審查者中出現的很頻繁，這使得那些嘗試代碼審查的人們體驗很不好，以至於成為了實踐代碼審查的障礙。
最重要的一個規則就是代碼審查的關鍵是在代碼提交之前發現代碼存在的問題-你要找的是正確性。代碼審查最常見的錯誤-每個初次接觸代碼審查的人都會犯的錯誤-就是判斷代碼是否是以審查者期望的方式編寫。
給定一個問題會有一打不同的方’案來解決，給定一個方案，會有一百萬種方式用代碼實現。作為一個審查者，你的工作不是確保代碼是以你所想象的那種方式編寫-這是不會的。你的工作是確保代碼是正確的。如果打破了這個規則，你會覺得代碼審查很難，充滿挫折感-這不是好事。
事實上，這是一個很自然的會犯的錯誤。如果你是一個程序員，當你看到一個問題的時候你會想到一個解決方案-而你會想當然的認為你所想到的就是那個解決方案。然而實際上不是-要成為一個好的審查者，你需要理解這點。
代碼審查第二個主要的坑就是人們覺得有義務說點什么。你知道作者花了很多時間和精力寫代碼-你難道不需要說點什么嗎？
不，你不需要。
只是說“哇，不錯”從來都不是一個錯誤。如果你總試圖費勁心思來找些什么東西批評一下，那么你所作的只會損害你的個人信譽。如果你只為了說點什么而不斷的制造點東西來評判，那么找你做代碼審查的人會覺得你所說的只是為了打破沉默，你的意見不會被認真考慮。
第三個坑和審查速度有關。你不應該匆忙的完成代碼審查，但是你也應該立刻開始。你的同事正在等你的反饋，如果你和你的同事不願意花時間來完快速成代碼審核，人們會變得沮喪，這種方式只會帶來挫折感。看起來代碼審查會中斷一些手頭的事情，但是事實上不會如此，如果有人要求你做審查，你不需要馬上放下所有事情，但是在接下來幾個小時里，你總會稍停你當前的工作-比如喝杯飲料，去洗手間或者散步閑聊。當你回來的時候，你可以開始審查並完成它。如果你這么做，那沒有人會因為等你而耽誤很長時間。
[英文原文：Things Everyone Should Do: Code Review ]