俗话说，没有无缘无故的爱，也没有无缘无故的恨，当然也没有无缘无故的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分：逻辑代码混乱复杂，理解起来极其空难