review 的checklist：
基本规范：
- 代码是否遵守开发规范和项目规范
- 组件或方法是否正确使用，是否重复造轮子, 是否未使用已有组件
- 函数或单个文件是否过度复杂, 是否容易理解、是否易于拓展、业务逻辑注释是否到位
- 对复杂的逻辑处理是否有兜底机制，是否会造成程序崩溃
- 文件划分或存放是否遵循规范
优化:
- hooks使用是否合理
- 是否有更优雅的写法
用户体验：
- button、modal 提交是否使用Promise包裹
- table loading 是否添加
less规范：
- 类名是否规范
- 类Modal组件 样式覆盖是否有层级包裹
- 是否 覆盖 ant-xxx 类名
三、codeReview流
review 流程节点
- 发起 merge request 到test分支
- 在企业微信 前端组群里 提出有 merge 任务
- reviewer 发现问题 群里截图 提出修改 并关闭 PR
- 修改完成重新发起上述流程
- 发布master时只需简单review
- 定期组织全员回顾 某个项目中心 或 某个开发人员的代码，优化checklist和reveiw问题
review 规则
- 完整功能尽量放在一个 PR 中
- 任何人都不能 合并自己的 merge request
- 代码在提交CODE REVIEW之前，开发者要自己先REVIEW和测试一遍
- 在产品验收时，提交 merge 进行 CR
review 评论
- [blocker]：在评论前面加上一个[blocker]标记，表示这个代码行的问题必须要修改；
- [optional]：在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改；
- [question]：在评论前面加上一个[question]标记，表示对这个代码行不理解，有问题需要问，被审查者需要针对问题进行回复澄；
- [check]：在review 完成后加上一个[check]标记，表示对这个 merge 中的代码确认审查；
【评论要友好，避免负面词汇；有说不清楚的问题当面沟通】
