關於CodeReview的一些思考與看法

語言: CN / TW / HK

theme: github

寫在前面:本篇文件是關於團隊實踐中CodeReview的一些個人想法,非常主觀。想法主要來源於日常工作的一些感想,以及參考了其他團隊的一些CodeReview規範和做法,有很多的地方考慮不周到,還請大家多多包涵。本篇文件的主要目的是拉起大家對於CodeReview的一些思考,如果看到這裡,已經燃起你對思考CodeReview這件事情的慾望了,那麼就請在這裡打住,不要再往下看了。

為什麼要拉CodeReview會?

從兩方參與變為三方參與。

兩方:reviewer,author

三方:reviewer,author,others

  • 對於author來說,

    • 拉會的形式能夠加速review的流程,高效迅速完成CodeReview,避免一個mr拖太久
    • 能夠引入更多的同學拉review自己的程式碼,減少低階錯誤,更好地提升和保障程式碼的質量
    • 拉會的形式對於author的邏輯表達能力有更高的要求,可以鍛鍊自己講解程式碼的能力,同時也是自己知識輸出的一種途徑
  • 對於reviewer來說,

    • 拉會的形式能夠幫助reviewer更好地理解程式碼邏輯,避免自己花大量時間看大段邏輯複雜的程式碼
    • 對於程式碼中有疑問的地方能夠直接提出疑問,並及時得到解答,提高review效率
    • 避免漏掉review一些比較小的點

程式碼評審有個重要的作用,那就是可以教會開發者關於語言、框架或者通用軟體設計原理。 ——from 谷歌 code review實踐

  • 對於others,

    • 新同學能夠學習到組內大佬的思路和解決方案,加速成長
    • 促進團隊內部知識共享,提高團隊整體水平

什麼時候應該拉CodeReview會?

  • 新增程式碼邏輯較為複雜,如新增某個介面or新增某個特性
  • 程式碼改動較大,如對某個模組進行了整體的優化or把程式碼改得面目全非了
  • 引入了新的技術或者新的架構

什麼時候不應該拉CodeReview會?

  • 程式碼改動較小或改動的邏輯較為簡單
  • mr上評論未解決,或檢查未通過

CodeReview流程

  • 會前

    • 程式碼已完成自測,並且提mr,邀請相關的reviewer
    • 提前一到兩天與主reviewers(至少一位主reviewer)約定時間,並將會議連結發到群裡,感興趣的同學可自行選擇參與

如何選擇主reviewers?

  1. 模組的負責人或者對模組熟悉度比較高的人
  2. 此次開發改動了對方的程式碼、邏輯
  3. 技術評審、需求開發過程中較為活躍或者貢獻出意見的人
  • 會中

    • author首先簡單同步一下需求的背景和改動的範圍
    • author整體過一遍程式碼,重點講述程式碼變動的地方和需要討論的地方
    • reviewer可隨時打斷,提出自己的疑問或者修改建議,author進行解答或反駁。
    • 注意氣氛,實施review時,要營造一個討論問題、解決問題的氛圍,不要搞成批判會或吵架會

    • author控制review的時間在1小時之內,避免長線作戰
  • 會後

    • author根據修改建議完成程式碼修改,並邀請reviewer再次評審,如無問題,reviewer可以點approve,然後合入