关于Code Review的一些思考总结
生活随笔
收集整理的這篇文章主要介紹了
关于Code Review的一些思考总结
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
Code Review
- 提高代碼質量
- 提前發現bug
- 統一代碼規范
- 提高團隊成員代碼技能
總之,前期找問題(代碼規范、潛在缺陷、BUG,代碼設計等等),后期演變成開發者技術交流和員工成長
如何開展
- 代碼規范:明確Coding規則
- 檢視清單:結合業務特點,check重點
- 總結優化:透明問題,持續優化
- 激勵措施:激發主觀能動性
開展方式
- 強制&非強制
- 線上交流(小組review)&線下會議(團隊review)
- 小片段&大模塊
- 發布前&發布后
- 高頻率&低頻率
阻力因素
- 領導或者團隊骨干不認同
- 為了疲于應付
- 以需求多,沒時間做為偷懶借口
組織類型
- 小組內review,通常是模塊負責人或者項目負責人review,頻率比較高,一天至少一次
- 團隊review,通常是整個團隊review代碼,團隊負責人牽頭,頻率可以低一點,鑒于公司情況一周至少1次吧
review內容
統一團隊代碼風格和編程規范
靜態代碼檢查工具
- Java類:Checkstyle、FindBugs、PMD、Infer等
- JavaScript類:JSLint、ESLint等
- Object-C類:OCLint、Clang Static Analyzer、Infer等
- **C#**類:StyleCode等
可以參考的一些編碼規范(github.com/Kristories/…)
發現『bad smell』的代碼以及bug
相關書籍:《重構-改善既有代碼的設計》《代碼整潔之道》
團隊成員好的經驗
- 什么寫法可能導致性能低下?
- 哪個接口要慎用?
- 哪些設計方式需要規避?
- 什么習慣容易引發內存泄漏? ……
開發者由于當初時間緊迫而覺得設計不合理的功能
- 功能不完善
- 設計有欠缺
- 代碼有更好實現方案
- 重視項目代碼的可讀性
總之,代碼是否符合團隊約定的代碼風格規范、代碼是否切合它所實現的業務、代碼是否安全、代碼性能、對后續開發者是否友好,即是否容易維護等
注意事項
- GitLab可以設置master和develop分支保護,開發者不能向這兩個分支push代碼,只能通過PR/MR形式。
- 可以通過設置git pre-commit hook來check,從而使不符合規范的代碼禁止提交倉庫。
- 配合CI檢查,作為build的第一步。
- 用戶角色有:所有者/主程/開發者/報告者/訪客,其中只有所有者和主程才有review代碼和合并代碼權限。
- 注意小組至少有兩個人有權限review并合并代碼,避免一個人請假或者不在,導致代碼合不上去。
- 主程一定要注意,避免過多模塊工作堆積在自己身上,一定要學會合理分配任務,因為你還需要有精力去review代碼,這也是一部分額外任務。
- 提交的 feature 分支全部走 gitlab 的 MR ,develop分支不允許提交,只用來合并,并且只合并那些經過review過的代碼,master分支不允許提交,也只用來合并,并且只合并來自develop分支的代碼。
- 不一定職稱越高,就更有可能比別人review代碼,code review知識共享更受重視,通過review發現bug是有的,但不是最終目的,增進團隊共識,保護團隊一致性其實更重要。
- 盡量避免開發經驗不足的開發者或者剛進公司對業務不熟悉的人員(哪怕高級工程師)review 代碼。
- 如果可以盡可能寫單元測試,不一定cover全面,如果時間緊迫可以只對關鍵模塊做。
- 提交PR/MR,記得在IM上通知相關人員review,比如項目負責人或者模塊負責人。
- 控制團隊review的時間,半個小時到1個小時,最好不要超過1個小時,30-40分鐘為宜,項目負責人具體把握。
- 根據公司情況團隊review一周在至少一次比較合適。
- review可能需要多次才被允許合入代碼,這也就意味著,可能你的代碼需要給多次修改才能改好。
- 避免代碼堆積,造成一次review大量代碼,一方面急于review,這樣容易放水,同時也浪費時間,造成效果不理想。
- 建議由1人做好記錄,把每次review的改進點以清單形式匯總列清楚發給所有參會人員。
總結
由于工期緊、需求變更快,如果不想清楚為什么要做 Code Review ,遇到障礙會非常容易妥協,慢慢 Code Review 就會走樣,最終流于形式。反之,在我們遇到障礙,review 代碼不順利時就會以積極的心態來解決問題。Code Review會影響開發效率,事實上追求高質量的代碼本身就降低了局部的開發效率,但是放眼長遠,這樣寫出來的代碼更加健壯,不會或很少出現“詭異”的bug,降低了后期維護的成本。
所以Code Review本身沒有問題,其實是人容易出問題。
總結
以上是生活随笔為你收集整理的关于Code Review的一些思考总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 让 Code Review成为一种习惯
- 下一篇: 如何进行高效迅速的CodeReview