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

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

• 編碼風格可以保持一致，目前團隊中雖然有編碼規范的指引，但在代碼抽查時，還是會看到很多「個性」的代碼；

• 將明顯問題扼殺在搖籃里，有時候存在設計上的一些錯誤，在后期要調整起來非常麻煩，改動大容易引發新的問題，還需要修復歷史數據等；

• 新人能夠快速融入團隊，知道團隊的編碼風格，能學習到一些優秀代碼的寫法，也能知道哪些是禁區，不能觸碰；

• 團隊成員之間能夠互相學習，構建良好的團隊氛圍。

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

• 從每天寫功能慢慢變成每天寫 Bug；

• 代碼的壞味道越來越濃，代碼變得難以維護；

• 修改一行代碼，測試沒有覆蓋到，往往就會帶來很嚴重的后果；

• 可能過一段時間，就需要進行大規模的重構；
  

• 新人的技能得不到快速提升。

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

• 項目急，時間緊，完成功能都需要加班加點，哪還有時間做 Code Review；

• 對 Code Review 的認知不足，不夠重視；

• 沒有相關的流程和制度進行約束，很難堅持執行下去。

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

Code Review 的工具和方式方法非常多，我們如果能挑一兩種方式，落地執行下去，就是非常好的一個開始。

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

1、核心代碼的改動

• 當前功能的提交是否有必要修改到這些地方，理由是什么？

• 這些代碼的改動有沒有可能引發一些嚴重問題？

2、MR 是誰提交的

• 如果是資深開發人員提交的代碼，Review 的粒度會比較粗；

• 如果是新人提交的代碼，則會重點關注，包括規范以及邏輯的合理性。

除此之外，我們領導推薦的一種做法，目前在團隊中一直在執行，就是寫代碼前先寫空方法。將任何的需求轉化成代碼，中間的思考過程是復雜的，需要考慮很多東西：性能、擴展、是否優雅等，反倒是最終的編碼實現相對是簡單的。

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

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

對于 Code Review ，我自己也還在不斷地探索和實踐，找到適合團隊的方法，執行下去，然后再持續進行改進和完善。

總結

以上是生活随笔為你收集整理的你有做 Code Review 吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。