讓團隊保持Code Review習慣的三大法寶

原文連接: alili.tech/archive/147…

以前跟你們聊過代碼審查,想要在團隊中保持團隊代碼審查習慣,是至關困難的. 咱們必需要有合理的流程,工具與制度的支持,才能基本保證咱們代碼審查效率與質量.

流程支持:Gitflow

以前有介紹Gitflow的工做流.

大體以下:

• 開發者在本地倉庫中新建一個專門的分支開發功能。
• 開發者push分支修改到公開的Git倉庫中。
• 開發者經過Git發起一個Merge Request。
• 團隊的其它成員代碼審查，討論並修改。
• 項目維護者合併功能到官方倉庫中並關閉Merge Request。

工具支持

強制使用eslint

強制使用eslint,在代碼未提交以前,是用husky等工具作強制eslint. 保證提交以後的代碼,必須先過一遍eslint.

規範提交代碼的類型

咱們本身內部開發了一款簡單的命令行工具,能夠在咱們提交代碼的時候,定義本次提交的類型.

方便咱們後續在代碼審查的時候,更加容易的理解修改的內容.

類型以下

• bug修復
• 新特性
• 樣式修復
• 代碼重構
• 測試代碼
• 代碼回滾
• bug修復
• 文檔更新
• 臨時提交

命令行使用方式

? What do you want to do? 代碼提交
? 請選擇Git提交類型？ (Use arrow keys)
❯ * fixed    : bug修復
  * feature  : 新特性
  * style    : 樣式修復
  * refactor : 代碼重構
  * test     : 測試代碼
  * revert   : 代碼回滾
  * doc      : 文檔更新
(Move up and down to reveal more choices)
複製代碼

Code Climate

Code Climate是一款代碼測試工具,它能夠幫助你進行代碼冗餘檢測、質量評估，同時支持多種語言，如PHP, Ruby, JavaScript, CSS, Golang, Python 等。

你能夠將他集成到GitLab-CI或者Travis CI中,當代碼提交後,會自動給出評估報告,以及修改建議.

gitlab與釘釘

在我如今的公司中,我在gitlab的基礎上作了二次開發,當有代碼審查任務的時候,可使用郵件或者釘釘通知到相關人員.

若是之後釘釘DING任務開放api,咱們甚至可使用釘釘來完成咱們一切的代碼審查任務的管理.

人工的代碼審查應該在全部持續集成的工做跑完以後才進行. 這樣能夠大大的減小咱們審查的工做量並且還保證了必定程度的代碼質量.

公司的支持

從公司層面上,也應該有相應的措施鼓勵代碼審查的工做.

• 鼓勵員工幫助別人審覈代碼，甚至能夠作到效績評估中。
• 制定統一的編程規範和代碼風格，特別是在那些有爭議的地方，可減小不少程序員偏好帶來的矛盾。

這是我最近對代碼審查的一些所思所想