你有做 Code Review 嗎?

語言: CN / TW / HK

在代碼的編寫中有一個很重要的環節,經常會被忽視,那就是 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 ,我自己也還在不斷地探索和實踐,找到適合團隊的方法,執行下去,然後再持續進行改進和完善。