程序員必備技能：代碼審查 (Google牛人談Code Review)

在上一篇博客裏我暗示本身將不在爲Google工做。 我尚未決定好去哪兒-有幾個很是不錯的工做機會讓我選擇。鑑於這段時間內我不受僱於任何公司，我想我能夠寫點和專業相關的東西，這些東西頗有趣，可是若是我還在職，可能會致使與同事/老闆的關係緊張。

Google是一個至關酷的公司。它們完成了一些很是讓人吃驚的事情-包括外部用戶能夠看到的，也包括公司內的。有些關於公司內部的東西是非保密性的，可是在公司外部討論的並不普遍，這些就是我想說的。

保證Google的代碼質量如此之好的最大緣由是代碼審查。這不是Google專有的-這是被廣爲接受的好主意，並且不少人都在作。可是我歷來沒有見過另一個大公司會應用的這麼廣泛，在Google,任何產品/項目的代碼只有獲得正面的審查才能夠提交。

每一個人都應該這麼作，我不是指非正式的:這是一個嚴格的軟件開發過程必備的廣泛規則，其範圍不僅包括產品代碼而是全部的代碼。這並不須要作不少工做，可是產生的效果很是大。

你能夠從代碼審查裏獲得什麼呢？

有一點很明顯，在代碼提交以前若是有不少雙眼睛盯着看能夠發現Bug.這是代碼審查最廣爲人知的好處，可是以個人經驗看這是價值最小的一點。人們的確能夠在代碼審查中發現Bug,可是這些Bug大部分都是顯而易見的小Bug,開發者分分鐘就能夠發現，而那些真正須要花時間發現的Bug一般不是在代碼審查中發現的。

代碼審覈最大的好處是純社會性的。若是你編程的時候知道你的同事將要看你的代碼，你的編程方式會不同。你的代碼會寫的更整潔，註釋更清楚，組織的更好-由於你知道其餘人會看你的代碼，他們的意見是你須要你關注的。若是沒有審查，你雖然知道人們最後會去看你的代碼，可是那樣不會給你一種緊迫感，也不會給你一樣的我的評判的感受。

還有一個更大的好處就是代碼審查能夠傳播知識。在不少的開發小組裏，每一個人都負責某一塊核心組件，專一於本身的這一塊，只要其餘同事的模塊不會破壞本身的代碼就不會去關注。這種模式致使一個模塊只有一我的熟悉對應的代碼。若是一我的請假或離職，其餘人對他負責的模塊將一無所知。若是採用代碼審覈，那麼至少有兩我的熟悉代碼-做者和審查者。審查者知道的代碼不如做者多，可是他們都熟悉代碼的設計和結構，這意義重大。

固然，沒有什麼事情會這麼簡單的，以個人經驗，你須要花一些時間來作好代碼審查。我已經見過一些坑致使的問題-因爲他們在經驗不足的審查者中出現的很頻繁，這使得那些嘗試代碼審查的人們體驗很很差，以致於成爲了實踐代碼審查的障礙。

最重要的一個規則就是代碼審查的關鍵是在代碼提交以前發現代碼存在的問題-你要找的是正確性。代碼審查最多見的錯誤-每一個初次接觸代碼審查的人都會犯的錯誤-就是判斷代碼是不是以審查者指望的方式編寫。

給定一個問題會有一打不一樣的方’案來解決，給定一個方案，會有一百萬種方式用代碼實現。做爲一個審查者，你的工做不是確保代碼是以你所想象的那種方式編寫-這是不會的。你的工做是確保代碼是正確的。若是打破了這個規則，你會以爲代碼審查很難，充滿挫折感-這不是好事。

事實上，這是一個很天然的會犯的錯誤。若是你是一個程序員，當你看到一個問題的時候你會想到一個解決方案-而你會想固然的認爲你所想到的就是那個解決方案。然而實際上不是-要成爲一個好的審查者，你須要理解這點。

代碼審查第二個主要的坑就是人們以爲有義務說點什麼。你知道做者花了不少時間和精力寫代碼-你難道不須要說點什麼嗎？

不，你不須要。

只是說「哇，不錯」歷來都不是一個錯誤。若是你總試圖費勁心思來找些什麼東西批評一下，那麼你所做的只會損害你的我的信譽。若是你只爲了說點什麼而不斷的製造點東西來評判，那麼找你作代碼審查的人會以爲你所說的只是爲了打破沉默，你的意見不會被認真考慮。

第三個坑和審查速度有關。你不該該匆忙的完成代碼審查，可是你也應該馬上開始。你的同事正在等你的反饋，若是你和你的同事不肯意花時間來完快速成代碼審覈，人們會變得沮喪，這種方式只會帶來挫折感。看起來代碼審查會中斷一些手頭的事情，可是事實上不會如此，若是有人要求你作審查，你不須要立刻放下全部事情，可是在接下來幾個小時裏，你總會稍停你當前的工做-好比喝杯飲料，去洗手間或者散步閒聊。當你回來的時候，你能夠開始審查並完成它。若是你這麼作，那沒有人會由於等你而耽誤很長時間。

[英文原文：Things Everyone Should Do: Code Review ]