當開始與其他工程師合作項目時 code review 就變成了必做的功課之一，然而許多工程師大多走馬看花地瀏覽過，不然就是大刀闊斧地把自己不順眼的地方大修特修。

而本文作者朱赟，現(xiàn)為美國硅谷 Airbnb 的資深工程師，向大家介紹了幾個 code review 時應(yīng)該注意的細節(jié)與架構(gòu)。我認為不管對初出茅廬，或是身經(jīng)百戰(zhàn)的工程師都有非常值得一看的價值。

之前寫過一篇《寫代碼的四個境界》，那個時候，大部分時候我還是愉快地寫著自己的代碼。Code review 也是每天工作的一部分，但是相對而言花的時間還是有限的。

最近一是因為角色轉(zhuǎn)換，二是突然來了很多新人。花在 code review 上的時間比寫代碼多出了好多，也有一些心得和感觸，隨便寫寫吧。

總的說來，硅谷稍具規(guī)模的公司 code review 的流程都是比較規(guī)范的。模式也差不多。一來所有的 PR（見下批注）都必須有至少一個人 stamp，才能 merge。如果改的東西涉及到多個項目，則需要每個項目都有人 stamp 才行。還有一些特別關(guān)鍵的代碼，比如支付相關(guān)的，通常也會需要支付組的人 stamp 才行。

NOTE: PR (pull request, a set of changes someone tries to push to a GitHub repository. Once a PR is sent, interested parties (peer engineers) can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

在 stamp 前，通常是 github page 上可以給出各種 comments，page 是共享的，所以誰都能看到。有些 comments 是詢問，那么代碼作者直接回復(fù)或解釋就行。有些 comments 是指出代碼的問題，這樣代碼作者可能會依此改動；也可能不同意，那就回復(fù) comments，有的時候關(guān)于一個實現(xiàn)細節(jié)，討論的 comments thread 可以多達十幾條。這樣對于大家達成共識很有幫助。

以前遇到有朋友說：

「看到代碼寫的太爛，覺得來回扯皮效率不高，干脆撲上去自己寫?！?/p>

曾經(jīng)我也有過類似的想法。不過最近遇到的一些事讓我慢慢地意識到這種想法很要不得。

首先就是從對方的角度來說。對方寫不好，可能是對業(yè)務(wù)不熟悉，可能是對語言不熟悉，也可能是對公司代碼的大架構(gòu)不熟悉。如果你是幫他/她「寫」而不是耐心指出哪里有問題，那么下一次，他/她可能還是不知道。不僅無益于別的人成長，有的時候甚至會讓別人有挫敗感。

再然后就是這種方式的可擴展性很差。即使 code review 會花掉哪怕十倍于你自己寫的時間和精力，但它會讓人明白代碼應(yīng)該怎么寫，從長遠來看，這其實是在一定程度上「復(fù)制」你的生產(chǎn)力。你不能什么都自己寫。尤其是你慢慢開始帶項目、帶新人。每天 review 五個人的代碼，和寫五個人的代碼，你覺得長期而言哪個更合算？

此外，如果說寫代碼是一個學(xué)習過程，怎么做一個好的代碼審核人更是一個學(xué)習和成長的過程。自己繞過一個坑不難，難的是看到別人那么走，遠遠地你就能告訴他/她那里有個坑。而他/她在經(jīng)你指出多次后，下一次他/她也會幫著指出別人的類似的問題。

這一點最近感觸尤為深刻。前一陣組里咔咔咔接二連三來了好多新人，老大說，你少寫點代碼，多做點 review。于是那幾天我?guī)缀豕ぷ鞯囊话霑r間都用來看代碼，寫 comments?？墒亲罱蜁l(fā)現(xiàn)，他/她們相互之間大部分時候已經(jīng)可以很好的相互 review 了，于是我又騰出好一些時間來做別的工作。

Code review 做多了，發(fā)現(xiàn)其實也是有一定套路的，試著歸納如下：

代碼格式方面

很多公司都有 coding style guideline。大家的約定俗成，避免公司的代碼風格不一致，也避免一些不不要的為了「要不要把閉括號另起一行」而無謂地爭論，除非是不小心，通常大家都不會弄錯。但是新員工往往會在這方面還不太熟悉。這一類問題也比較容易指出。

代碼可讀性方面

這包括一個函數(shù)不要太長，太長就 break down。所有的變量名盡量能夠說明它的用意和類型。比如 hosting_address_hash，一看就知道是房東地址，而且是個 hash 類型。不要有嵌套太多層的條件語句或者循環(huán)語句。不要有一個太長的 boolean 判斷語句。如果一個函數(shù)，別人需要看你的長篇注釋才能明白，那這個函數(shù)就一定有重構(gòu)的空間。另外，如果不可避免有一些注釋，則一定要保證注釋準確且與代碼完全一致。

幫代碼作者想想他/她有沒有漏掉任何 corner case

很多時候這是業(yè)務(wù)邏輯相關(guān)的，尤其需要比較老的工程師幫助指出需要處理的所有情況。

Error handling

這是最常見也是代碼審核最容易幫別人看出的問題。舉個例子，下面一段簡單到不能再簡單的代碼就至少有三個潛在的問題：params 里面需要 validate 是不是有 user_id 和 new_name 這兩個 key；能不能找到這個 user_id 對應(yīng)的 user；save 的時候會不會有 DB level 的 exception，應(yīng)該怎么處理。

測試例和防坑

測試例不用說了，每段代碼都應(yīng)該有測試例。但是對于一些你能預(yù)見如果別人改動代碼會引起可能問題的情況，一定要額外的加測試例防止這種事情的發(fā)生。這一點沒有例子參考也不太好說。怎么寫好測試例，本身就值得寫一篇文章了。

小架構(gòu)

什么意思呢，就是一個文件或者類內(nèi)部的代碼組織。比如如果有重復(fù)的代碼段，就應(yīng)該提取出來公用。不要在代碼里隨意設(shè)常數(shù)，所有的常數(shù)都應(yīng)該文件頂部統(tǒng)一定義。哪些應(yīng)該是 private，等等

大架構(gòu)

這個就更廣了。包括文件組織，函數(shù)是不是應(yīng)該抽像到 lib 或者 helper 文件里；是不是應(yīng)該使用繼承類；是不是和整個代碼庫的風格一致，等等。

當然，視具體情況可能還有很多別的需要在 code review 中注意的。但是如果按照這個 checklist 過一遍，一些明顯的問題就可以避免個八九不離十了。

另外，代碼 review 和寫代碼是我們每個工程師都應(yīng)該致力的兩個方面，缺一不可?？赡茉诠ぷ髦械哪硞€階段或者某個項目里，你會花更多的時間在某一面，但長久看來，兩個技能缺一不可。

代碼審核是工作，不要抱有情緒化

我曾經(jīng)干過一件事，一個外組同事的代碼，別人已經(jīng) stamp 了，可是我覺得有問題，于是把 stamp revert 掉了，在 comments 里寫了為什么有問題，和建議的改法。當時心里還有點覺得好像怪得罪人的。可是后來發(fā)現(xiàn)同事反而很客氣地接受并道謝了。心里也是很感激有這樣的工作環(huán)境。

另外，經(jīng)常會遇到有些 review 的 comments 里出現(xiàn)不同意見，其實是兩個人在編程習慣和約定俗成上沒有共識。如果在不違背公司 style guideline 的情況下，沒必要一定讓對方和你有一樣的習慣。如果你真的覺得這樣更好，通常我也只會寫「I personally would prefer A over B, but no strong opinion.」或者「How about change it to A, since … However, this is not a merge blocker. 」

人都有不周到的時候。多幾雙眼睛一起幫你看一遍，就可以很大程度地減少代碼里的錯誤。另外，相互 review 的過程中還能從彼此那里學(xué)到很多編程的小技巧和好習慣。細想來，很多 Java 和 Ruby 的特別好用的 feature，我都是在 code review 的過程中學(xué)到的。

文章引用：http://www.duhuilife.cn/new/201.html

本站文章為深圳網(wǎng)站建設(shè)·源美網(wǎng)絡(luò)原創(chuàng)策劃，如有版權(quán)糾紛或者違規(guī)問題，請聯(lián)系我們刪除，謝謝！