让团队保持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,咱们甚至可使用钉钉来完成咱们一切的代码审查任务的管理.

人工的代码审查应该在全部持续集成的工做跑完以后才进行. 这样能够大大的减小咱们审查的工做量并且还保证了必定程度的代码质量.

公司的支持

从公司层面上,也应该有相应的措施鼓励代码审查的工做.

• 鼓励员工帮助别人审核代码，甚至能够作到效绩评估中。
• 制定统一的编程规范和代码风格，特别是在那些有争议的地方，可减小不少程序员偏好带来的矛盾。

这是我最近对代码审查的一些所思所想