导读：是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工
一、检查登记
1、项目名称
2、系统模块
3、开发人员
4、检查人员
5、检查时间
6、检查用时
二、后端检查
| 序号 | 检查项 | 检查结果 | 备注 |
|---|---|---|---|
| 1 | 是否使用有意义的命名，是否有必要的注释 | 通过/不通过/不适用 | |
| 2 | 判断逻辑是否正确处理和更新 | 通过/不通过/不适用 | |
| 3 | 对于循环操作，检查是否会陷入死循环，是否在循环中创建公用对象 | 通过/不通过/不适用 | |
| 4 | 对于租户数据，是否严格要求租户ID参数 | 通过/不通过/不适用 | |
| 5 | 接口数据接收是否设置有严谨的数据验证器 比如特殊字符、空字符串、null等 | 通过/不通过/不适用 | |
| 6 | 是否重复多次请求接口 | 通过/不通过/不适用 | |
| 7 | 返回类型是否有做区分 | 通过/不通过/不适用 | |
| 8 | 是否处理null值情况，是否捕捉异常，记录异常日志 | 通过/不通过/不适用 | |
| 9 | 是否有必要的权限验证 | 通过/不通过/不适用 | |
| 10 | 数据处理条件是否合理（更新删除都有必要的where条件） | 通过/不通过/不适用 | |
| 11 | 任务调度有无安全退出、有无滥用sleep、大内存是否及时释放 | 通过/不通过/不适用 |
三、前端检查
| 序号 | 检查项 | 检查结果 | 备注 |
|---|---|---|---|
| 1 | 项目的工程结构（目录、文件位置）是否标准、合理 | 通过/不通过/不适用 | |
| 2 | 命名是否规范和具有语义性，是否表明变量、函数等作用 | 通过/不通过/不适用 | |
| 3 | 是否有必要的注释，格式是否规范，并描述清楚代码用途 | 通过/不通过/不适用 | |
| 4 | 是否消除类似或重复的代码 | 通过/不通过/不适用 | |
| 5 | 是否及时销毁定时器、监听器 | 通过/不通过/不适用 | |
| 6 | 是否删除了非必要console/调试代码、多余文件、依赖 | 通过/不通过/不适用 | |
| 7 | 不同环境的逻辑是否进行区分（如process.env.NODE_ENV，静态资源） | 通过/不通过/不适用 | |
| 8 | 存在第三方库/函数、项目已有逻辑可用，而非重新开始 | 通过/不通过/不适用 | |
| 9 | 在项目支持的情况下，是否使用新语法编码（ES6等） | 通过/不通过/不适用 | |
| 10 | TypeScript项目中的类型、模块等声明是否正确 | 通过/不通过/不适用 | |
| 11 | 页面布局、元素位置是否相对灵活（flex、百分比等而不是absolute） | 通过/不通过/不适用 |
四、检查步骤
1、检查开发者的代码实现是否遵循了上述清单要求。
2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。
3、代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，
代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。
4、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。
审核完毕后，代码审核者记录发现的问题及修改建议，提交给相关人员。
5、代码编写者根据审核人员给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。
6、代码编写者bugfixed完毕之后给出反馈。
7、代码审核者把检查中发现的有价值的问题更新到"代码检查“清单，由相关人员同步到协作中心。
五、检查备注
检查结果可以填写通过、不通过、不适用三种，如不适用，需要备注原因；
本检查单非单个项目使用一次，检查单按开发人员的个数和功能点进行区分。