在代碼的編寫中有一個很重要的環(huán)節(jié)，經(jīng)常會被忽視，那就是 Code Review ,據(jù)說在 Facebook、Google 這種互聯(lián)網(wǎng)大公司，要求每一個提交都必須通過審查，對于每個工程師來說 Code Review 是一項十分重要的工作，甚至比寫代碼本身更重要。

這里所說的 Code Review 是指人工的方式進(jìn)行代碼的檢查，通常會給我們帶來下面的一些好處：

• 編碼風(fēng)格可以保持一致，目前團(tuán)隊中雖然有編碼規(guī)范的指引，但在代碼抽查時，還是會看到很多「個性」的代碼；
• 將明顯問題扼殺在搖籃里，有時候存在設(shè)計上的一些錯誤，在后期要調(diào)整起來非常麻煩，改動大容易引發(fā)新的問題，還需要修復(fù)歷史數(shù)據(jù)等；
• 新人能夠快速融入團(tuán)隊，知道團(tuán)隊的編碼風(fēng)格，能學(xué)習(xí)到一些優(yōu)秀代碼的寫法，也能知道哪些是禁區(qū)，不能觸碰；
• 團(tuán)隊成員之間能夠互相學(xué)習(xí)，構(gòu)建良好的團(tuán)隊氛圍。

不做 Code Review 也能完成功能的實現(xiàn)，只不過慢慢會帶來下面的問題：

• 從每天寫功能慢慢變成每天寫 Bug；
• 代碼的壞味道越來越濃，代碼變得難以維護(hù)；
• 修改一行代碼，測試沒有覆蓋到，往往就會帶來很嚴(yán)重的后果；
• 可能過一段時間，就需要進(jìn)行大規(guī)模的重構(gòu)；
  
• 新人的技能得不到快速提升。

其實我們都知道 Code Review 的重要性，敏捷開發(fā)中的結(jié)對編程就包含了 Code Review ，但為什么卻難以執(zhí)行呢，我認(rèn)為有下面一些原因：

• 項目急，時間緊，完成功能都需要加班加點，哪還有時間做 Code Review；
• 對 Code Review 的認(rèn)知不足，不夠重視；
• 沒有相關(guān)的流程和制度進(jìn)行約束，很難堅持執(zhí)行下去。

我們團(tuán)隊的代碼采用私有 GitLab 服務(wù)器，自然也使用了 GitLab 中的 MR 模式，不清楚 MR 是什么的同學(xué)可以看看我之前寫的《在團(tuán)隊中使用 GtiLab 中的 Merge Request 工作模式》。曾經(jīng)有一個美好的設(shè)想就是利用 Merge Request ，讓每個人都能參與進(jìn)來，在 GitLab 中進(jìn)行代碼的討論，但非常遺憾，最終沒能執(zhí)行起來。

Code Review 的工具和方式方法非常多，我們?nèi)绻芴粢粌煞N方式，落地執(zhí)行下去，就是非常好的一個開始。

上面說到 Merge Request ?在團(tuán)隊中沒有推行起來，但我個人還是在經(jīng)常使用，我是代碼合并的管理員之一，當(dāng)合并代碼時，我會重點關(guān)注兩個方面：

1、核心代碼的改動

• 當(dāng)前功能的提交是否有必要修改到這些地方，理由是什么？
• 這些代碼的改動有沒有可能引發(fā)一些嚴(yán)重問題？

2、MR 是誰提交的

• 如果是資深開發(fā)人員提交的代碼，Review 的粒度會比較粗；
• 如果是新人提交的代碼，則會重點關(guān)注，包括規(guī)范以及邏輯的合理性。

除此之外，我們領(lǐng)導(dǎo)推薦的一種做法，目前在團(tuán)隊中一直在執(zhí)行，就是寫代碼前先寫空方法。將任何的需求轉(zhuǎn)化成代碼，中間的思考過程是復(fù)雜的，需要考慮很多東西：性能、擴(kuò)展、是否優(yōu)雅等，反倒是最終的編碼實現(xiàn)相對是簡單的。

而寫空方法的過程就是思考的過程，涉及到了類的創(chuàng)建、抽象、組合；方法的職責(zé)，事先沒有思考清楚，是寫不出來的。

快速出一版空方法后，再進(jìn)行溝通和討論，找出其中有遺漏和有問題的點，進(jìn)行修改，最終的版本在大方向上基本是沒什么問題的。

對于 Code Review ，我自己也還在不斷地探索和實踐，找到適合團(tuán)隊的方法，執(zhí)行下去，然后再持續(xù)進(jìn)行改進(jìn)和完善。