前端团队codeReview规范以及流程
俗话说,没有无缘无故的爱,也没有无缘无故的恨,当然也没有无缘无故的Code Review!
一、目的
- 保证团队编码风格一致
- 自己的代码要给别人看,开发过程中需要潜意识的注意代码规,以及逻辑严谨性。
- 保证项目质量,扼杀潜在风险
- 虽然功能完成后自己会自测,但难免会遗漏掉一些边界点,或者受思维限制的一些点。
- 相互提升
- 多学习别人代码,看高手是如何写出严谨、简洁、优美的代码,和自己做对照,取齐精髓,去其糟粕!
- 便捷交叉维护
- 通过交叉Code Review过程,了解不同业务,方便后期交叉维护,无需花更多时间上手。
二、如何开展
- 结对
- 至少两人为一小组
- review以及上线流程
- 所有项目master设置为Protected,并且设置allowed to push为No one,设置Merge checks为All discussions must be resolved,该分支作为deployment分支
- 开发时创建dev分支,并且同样设置为Protected,allowed to push为No one,设置Merge checks为All discussions must be resolved,该分支作为development分支
- 个人分支最好以自己名字命名,需要review代码时,提Merge Request到dev分支,代码review人对代码进行review,对不符合规范的代码编辑comment,直到代码没有问题后标记comment为resolved(此时分支才会允许merge)
- dev分支经过测试没问题上线之后,提MR到master分支,至此项目才真正上线完成
- 集体
- 每周周会集体review代码,每次review核心代码,预期每周集体review三位同学代码
- 各自讲解自己的模块,复杂业务最好有流程图
- git hooks – pre commit
- 新项目统一使用ESLint作为代码规范检测工具,每次Git commit会判断代码是否符合规范,只有符合规范的才能被提交
三、自测check list
之前都说在功能完成之后要进行自测,但具体从哪些方面切入没有定义,之后大概可以从以下方面切入:
- 常规检查
- 代码是否能正常运行?
- 控制台是否有明显的报错?
- 代码有没有达到预期需求效果?
- 代码逻辑是否简单易懂?代码书写是否符合规范?是否尽可能组件化了?
- 有没有重复造轮子?
- 去掉大段被注释的代码?(如果注释代码是可用的,那就先提交未删除注释的代码到Git上,然后再提交删除了注释的代码,以后能回滚就可以)
- 定时器是否随生命周期消除?按钮是否控制了单次点击?
- 安全检查
- 引入他人(公司内部或者其他外部机构)依赖包,是否存在不可用和版本升级导致功能不可用的风险?
- 所有请求是否都使用了https,包括图片链接,对App应用嵌入的页面,是否提供了https协议链接?
- 代码注释或者文案中是否包含了敏感词汇?
- 文档检查
- 是否有符合规范的注释?注释是否描述准确?对方法参数或者名词是否进行了解释?
- 第三方库使用是否有完善文档?
- Readme文档是否书写规范?是否对项目有准确描述?
- 性能检查
- 页面加载是否超过了3s?超过3s的原因是什么?有没有友好的提示?
- 代码有没有明显影响性能的逻辑和计算?
- 组件层级是否可控?组件通信是否正常?页面嵌套是否简单?
四、评分标准
总分30分,24分以上是允许被merge到master的代码,低于24分需要进行优化之后再提MR。
- 需求
- 9-10分:项目结构清晰,组件合理,代码逻辑严谨,功能无遗漏
- 6-8分:无逻辑错误,功能无遗漏
- 0-5分:代码逻辑错误,功能遗漏
- 代码
- 9-10分:代码简洁,合理注释,模块独立
- 6-8分:模块中度耦合,代码相对简洁
-0-5分:模块耦合度较高,代码注释不清晰,代码书写复杂,命名不规范
- 可读性
- 9-10分:严格的代码规范,代码逻辑易理解,注释清晰
- 6-8分:存在阅读障碍的逻辑代码,注释模糊
- 0-5分:逻辑代码混乱复杂,理解起来极其空难