爲何要堅持code review

我的經歷

首先聊聊我code review的經歷，當時剛剛來到百度，負責FE這邊的高T是從Google過來的，據說他將不少Google那邊的風格複製到了百度，其中code review就是重要的一塊。

code review在我入職時，能夠說是嚴格到使人髮指，代碼不經過沒法提交，並且常常佔用整個開發時間的大約40%。我當時的一段代碼能夠說常常被打回來5，6次。有時最終提交的代碼都直接重構了當初的初版。我也曾經由於code review，好幾回差點耽誤了開發進度。。

而如今我常常做爲審覈人員去review其餘同窗的代碼，有時就感慨，因爲項目的壓力，如今沒有之前那麼嚴格的，可是code review我仍是認爲須要堅持下去的。

此外據我瞭解，即便在百度內部強制了code review，可是不少部門也沒有徹底執行。

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即不用浪費不少時間，並且問題都能快速暴露，快速修復。代碼始終都能在保證在一個正確的方向上。

博客地址

http://tangguangyao.github.io/

微信微信公衆號