一、CodeReview意义
- 提升团队代码设计水平
- 确保代码设计和实现一致（前提需要有技术设计一环）
- 厘清业务逻辑细节，尤其是涉及多条业务线的情况
二、CodeReview问题
2.1 对于提交代码的同学：
1、不清楚提交代码 CR 的范围？
2、不清楚需要给哪些人提交代码 CR？
3、怎样才能让别人认真评审代码？
2.2 对于参与评审代码的同学：
1、不清楚需要 CR 代码的业务上下文是怎样的，不容易判断代码结构设计的合理性；
2、一下子提交几千行代码，哪些代码是 CR 的重点内容，哪些不是；
三、代码编写规范
1. Java: 参考阿里编码规范
2.代码审核清单：
| 常规项 | 1 | 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。 |
| 2 | 所有的代码是否简单易懂？ | |
| 3 | 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。 | |
| 4 | 是否存在多余的或是重复的代码？（应该抽取） | |
| 5 | 代码是否尽可能的模块化了？ | |
| 6 | 是否有可以被替换的全局变量？ | |
| 7 | 是否有被注释掉的代码？ | |
| 8 | 循环是否设置了长度和正确的终止条件？ | |
| 9 | 是否有可以被库函数替代的代码？ | |
| 10 | 是否有可以删除的日志或调试代码？ | |
| 安全 | 1 | 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？ |
| 2 | 在哪里使用了第三方工具，返回的错误是否被捕获？ | |
| 3 | 输出的值是否进行了检查并且编码？ | |
| 4 | 无效的参数值是否能够处理？ | |
| 文档 | 1 | 是否有注释，并且描述了代码的意图？ |
| 2 | 所有的函数都有注释吗？ | |
| 3 | 对非常规行为和边界情况处理是否有描述？ | |
| 4 | 优先使用工业化的第三方库，衡量标准经过了大量的时间及完整文档，还有专人或组织维护 | |
| 5 | 重要的数据结构和计量单位需要进行解释 | |
| 6 | 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如'TODO'？ |
四、代码评审的方式
4.1 针对线上和线下评审的基本原则：
1、when(什么时候提交): 子任务开发完成, 由代码提交者发起。
2、who（谁参与）:
a) 参与人：主讲人，评审者，如果是线下评审需要有一名记录者，以提升整体评审，问题记录效率;
b) 提交给谁：
1、向团队中经验丰富的程序员提交 CR，以便于获得更加高水平的代码设计反馈；
2、大团队划分小组，小组内进行交叉CR
3、what（提交内容说明）: 在提交评审的时候，需要附上一定的说明，阐述清楚这些代码主要实现逻辑（如果太大可以附上技术设计的链接和需求文档链接），主要核心逻辑在哪些文件中，这样 reviwer 在评审代码的时候可以有的放矢。4、others (其他):
1、在迭代总结前：针对CR提出的问题需要进行总结，沉淀。 (问题沉淀模版，尽量减少大家总结时间)
4.2 线上评审
单人评审：gitlab上提交给reviewer进行在线评审
线上评审一般是主要的代码 CR 方式，但是在提交评审的时候还是要遵循一定的原则，以便于提高代码评审的效率。
每次提交 CR 的代码不能超过200行，如果超过400行则需要转线下评审（建议前期子任务尽量拆分的比较合理，如果每次评审的时候一下子推给别人几千行代码，估计对应的 reviwer 看都不想看，很难保证 review 的质量）；
4.3 线下评审
线下评审的基础条件：涉及多个依赖模块或者CR 代码行超过400行
1、where: 由主讲人预定线下会议（或者腾讯会议室），邀请必须参与的角色。
2、Time: 时间不超过2个小时
五、评估机制
|
|
指标名称
|
计算公式
|
说明
|
|---|---|---|---|
| 1 | 单个有效评论成本 | CR投入工时/CR数 |
CR投入工时数据获取可能不会太准确，尤其是线上评审部分 线下部分可以通过每次评审记录表进行收集反馈，并上传到Jira |
| 2 | 有效问题数 | 提交有效的CR评论数 | 如果确定有效的CR数？确定要解决的CR数属于有效CR数？ |
| 3 | CR消耗工时 | CR结束时间-CR开始时间 | 代表投入成本 |
| 4 | 有效CR率 | 有效的CR评论数/总的CR评论数 | 总的CR评论数，可以通过api 接口获取 |
| 5 | 大提交占比 | 单次提交超过200行代码CR数/总CR数 | |
| 6 | 自评占比 | 自评CR数/总CR数 | |
| 7 | 人员参与度 | 参与CR的人数/总人数 | |
| 8 | 问题漏出率 | 1- CR召回的问题数/CR可召回的问题数 |
六、奖励机制
- 每个迭代总结选出1-3名CR中提出高质量问题的同学。
- 每个迭代总结选出1-3名参与CR 次数最多的同学。
