為什麼要堅持code review

code review在我入職時，可以說是嚴格到令人髮指，**不通過無法提交，而且經常占用整個開發時間的大約40%。我當時的一段**可以說經常被打回來5，6次。有時最終提交的**都直接重構了當初的第一版。我也曾經因為code review，好幾次差點耽誤了開發進度。。

而現在我經常作為審核人員去review其他同學的**，有時就感慨，由於專案的壓力，現在沒有以前那麼嚴格的，但是code review我還是認為需要堅持下去的。

有和沒有之間的態度差別

很簡單，一段**完成之後，有人看和沒有人看，在質量上還是會有差別的。

當你知道你的**會被人一行一行review時，你的**一定為努力寫的最好，而不是為了完成功能而應付了事，這就是態度上的區分。因為當你知道你寫的**是有人看的，你會更加在意你寫的東西，你一定不想背後被人說，**寫的像一坨**。

而且確實我自己在review**時，就能看出哪些為了趕上線而寫的就和平常寫的會有差別。

**的可讀，可維護

**的可讀和可維護在大團隊很關鍵，最初我們**審核為什麼嚴格到令人髮指，就是因為可讀性和可維護性。

嚴格的code review可以感覺整個團隊寫出的**就像是乙個人寫的。這樣就是為了能讓你隨時切換到其他業務上，而且不需要什麼適應時間。

可讀性和可維護對於大型的多人合作系統，可以說非常關鍵，當乙個團隊30多人在乙個單頁面開發時，如果風格各異，**僅僅符合功能和測試要求的話，你會發現多人開發的成本和新需求的公升級的成本會越來越高。

舉個常見的例子：

如果某個業務突然需要提高進度，這時的辦法就是加人力，但是如果**風格各異，加入的人力適應時間和學習成本是極高的，有時甚至不如保持原有人力去加班hold。要不就只能找些技術很強，可以無障礙學習的資深工程師江湖救急。

我們這邊其實就是會出現上面專案突然加急的情況，但是，因為有code review，所以我們多人合作時，基本上可以保證1+1≈2的效率。為什麼這麼任性，就是因為在code review時已經控制了大家的寫法和模式，讓新加入的同學能夠馬上看懂以前邏輯並且做大概的業務了解就能上手了。

我這邊最近就經歷了這些，因為需要還一些歷史遺留的技術債務，所以我需要調整底層的一些**結構，這時保證功能和互相呼叫ok的情況下切換**位置和路徑就是我遇到的最大的障礙。

不過由於之前業務**的高質量和開發模式基本上完全一致，所以我能很快找到統一的切入點，預先就能預估好可能會踩的坑。

如果沒有code review之前嚴格的約束，我基本上需要每個業務功能去分析了，效率降到極低。

對於新人，快速引導，快速反饋

對於新人加入我們的團隊，最快的上手方式就是，簡單熟悉完之後，接手乙個業務專案，然後我們會通過不斷的code review給與開發方式，編碼習慣，設計模式之間的反饋。

第乙個專案的review 基本上會是最嚴格的。

其實對於技術人員，code review 就是用**在做溝通。

及時發現非**上的問題

有時我在review**時會發現，有些地方經常在反覆修改，或者有時實現會非常彆扭。這時我就會問開發人員，是不是需求不明確導致的，是不是對需求的理由有偏差。

因為對於正在開發的同學，經常會陷入到業務具體的實現中，有時就是饒了很大的圈子但是自己確不知道。這時review時是能感覺到的，而且我也成功的多次阻止過。

很很多團隊拒絕code review 主要是基於時間不允許，專案追的太緊之類的。

不過因為我也經歷過沒有code review的開發方式，我的感受是code review的影響不會有大家想的那麼嚴重。

這裡關鍵是具體如何去做

舉例：

在開發乙個新模組時，由於對於業務的開發模式不熟悉，上來就直接把功能什麼的，需求什麼的都搞定了。洋洋灑灑幾千行**的產出。最後需要提交時，review的人發現，我靠。。。這種實現不是我需要的，以後會埋很多坑啊。這時怎麼辦，重構？時間夠嗎，還是就這樣了，把坑留給二期？

我們要求的code review不是上面那種，我們要求每次提交的內容盡量少，完成乙個小的功能點就可以提交。這樣review的人看起來也會越快，反饋的時間也會約迅速。

例如，完成目錄結構和框架就可以提交一版，這時可以review檔案名字起的是否合理之類的。

在每次提交**的時間上，我們也是期望每天都會有提交，最長也不要超過3天，不然最後提交的**對於review的人也是負擔，出現的問題也不一定來得及修復。如果長期這樣，確實是會影響到開發效率。

其實合理的code review即不用浪費很多時間，而且問題都能快速暴露，快速修復。**始終都能在保證在乙個正確的方向上。