原文連結: 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,我們甚至可以使用釘釘來完成我們一切的程式碼審查任務的管理.
人工的程式碼審查 應該在所有持續整合的工作跑完之後才進行.這樣可以大大的減少我們審查的工作量而且還保證了一定程度的程式碼質量.
公司的支援
從公司層面上,也應該有相應的措施鼓勵程式碼審查的工作.
- 鼓勵員工幫助別人稽核程式碼，甚至可以做到效績評估中。
- 制定統一的程式設計規範和程式碼風格，特別是在那些有爭議的地方，可減少很多程式設計師偏好帶來的矛盾。
這是我最近對程式碼審查的一些所思所想