首页 关于Code Review的一些思考总结
文章
取消

关于Code Review的一些思考总结

Code Review

  • 提高代码质量
  • 提前发现bug
  • 统一代码规范
  • 提高团队成员代码技能

总之,前期找问题(代码规范、潜在缺陷、BUG,代码设计等等),后期演变成开发者技术交流和员工成长

如何开展

  • 代码规范:明确Coding规则
  • 检视清单:结合业务特点,check重点
  • 总结优化:透明问题,持续优化
  • 激励措施:激发主观能动性

开展方式

  • 强制&非强制
  • 线上交流(小组review)&线下会议(团队review)
  • 小片段&大模块
  • 发布前&发布后
  • 高频率&低频率

阻力因素

  1. 领导或者团队骨干不认同
  2. 为了疲于应付
  3. 需求多,没时间做为偷懒借口

组织类型

  • 小组内review,通常是模块负责人或者项目负责人review,频率比较高,一天至少一次
  • 团队review,通常是整个团队review代码,团队负责人牵头,频率可以低一点,鉴于公司情况一周至少1次吧

review内容

统一团队代码风格和编程规范

静态代码检查工具

  1. Java类:Checkstyle、FindBugs、PMD、Infer等
  2. JavaScript类:JSLint、ESLint等
  3. Object-C类:OCLint、Clang Static Analyzer、Infer等
  4. C#类:StyleCode等

可以参考的一些编码规范(https://github.com/Kristories/awesome-guidelines)

发现『bad smell』的代码以及bug

相关书籍:《重构-改善既有代码的设计》《代码整洁之道》

团队成员好的经验

  • 什么写法可能导致性能低下?
  • 哪个接口要慎用?
  • 哪些设计方式需要规避?
  • 什么习惯容易引发内存泄漏? ……

开发者由于当初时间紧迫而觉得设计不合理的功能

  • 功能不完善
  • 设计有欠缺
  • 代码有更好实现方案
  • 重视项目代码的可读性

总之,代码是否符合团队约定的代码风格规范、代码是否切合它所实现的业务、代码是否安全、代码性能、对后续开发者是否友好,即是否容易维护等

注意事项

  1. GitLab可以设置master和develop分支保护,开发者不能向这两个分支push代码,只能通过PR/MR形式。
  2. 可以通过设置git pre-commit hook来check,从而使不符合规范的代码禁止提交仓库。
  3. 配合CI检查,作为build的第一步。
  4. 用户角色有:所有者/主程/开发者/报告者/访客,其中只有所有者和主程才有review代码和合并代码权限。
  5. 注意小组至少有两个人有权限review并合并代码,避免一个人请假或者不在,导致代码合不上去。
  6. 主程一定要注意,避免过多模块工作堆积在自己身上,一定要学会合理分配任务,因为你还需要有精力去review代码,这也是一部分额外任务。
  7. 提交的 feature 分支全部走 gitlab 的 MR ,develop分支不允许提交,只用来合并,并且只合并那些经过review过的代码,master分支不允许提交,也只用来合并,并且只合并来自develop分支的代码。
  8. 不一定职称越高,就更有可能比别人review代码,code review知识共享更受重视,通过review发现bug是有的,但不是最终目的,增进团队共识,保护团队一致性其实更重要。
  9. 尽量避免开发经验不足的开发者或者刚进公司对业务不熟悉的人员(哪怕高级工程师)review 代码。
  10. 如果可以尽可能写单元测试,不一定cover全面,如果时间紧迫可以只对关键模块做。
  11. 提交PR/MR,记得在IM上通知相关人员review,比如项目负责人或者模块负责人。
  12. 控制团队review的时间,半个小时到1个小时,最好不要超过1个小时,30-40分钟为宜,项目负责人具体把握。
  13. 根据公司情况团队review一周在至少一次比较合适。
  14. review可能需要多次才被允许合入代码,这也就意味着,可能你的代码需要给多次修改才能改好。
  15. 避免代码堆积,造成一次review大量代码,一方面急于review,这样容易放水,同时也浪费时间,造成效果不理想。
  16. 建议由1人做好记录,把每次review的改进点以清单形式汇总列清楚发给所有参会人员。

总结

由于工期紧、需求变更快,如果不想清楚为什么要做 Code Review ,遇到障碍会非常容易妥协,慢慢 Code Review 就会走样,最终流于形式。反之,在我们遇到障碍,review 代码不顺利时就会以积极的心态来解决问题。Code Review会影响开发效率,事实上追求高质量的代码本身就降低了局部的开发效率,但是放眼长远,这样写出来的代码更加健壮,不会或很少出现“诡异”的bug,降低了后期维护的成本。

所以Code Review本身没有问题,其实是人容易出问题。

本文由作者按照 CC BY 4.0 进行授权

JavaScript基础之发布-订阅模式EventEmitter的实现

基于Hacker News的内容热度推荐算法