代码审查清单样例(附:代码审查建议)
要想做好代码审查,一份审查清单是必不可少的。这样大家就都有了一个标准,可以在代码审查过程中按照审查清单逐一检查。使用审查清单可以帮助审查者快速找到问题,甚至开发者在开发阶段就可以按照审查清单进行代码自查。


网上有很多代码审查清单,但是不同的团队可能需要不同的代码审查清单,这需要根据团队的实际情况进行调整和完善。不过一般来说,一份代码审查清单通常应该包括如下几个大的类目。
1,代码结构
- 是否包含超长代码
- 代码层次嵌套是否过深
- 函数是否入参过多
- 循环条件是否有跳出点
- if 语句是否有对应的 else 语句
- 是否存在重复的代码
2,代码安全性
- I/O 流是否正常关闭
- 资金计算是否使用了 Double 数据类型
- 是否有超大的临时对象
- 线程池大小是否合理
- 是否考虑了线程安全(比如静态 Util 或单例必须是线程安全的,DateFormat 类是非线程安全的,在作为全局常量使用时建议采用包装 DateUtil 工具类)
- 异常是否被忽略
- 是否有详细的日志记录
- 是否存在并发问题
- 参数是否做了必要的检查
- 远程服务的入参出参是否实现了 Serialization 并且自定义了 serialVersionUID
- 应用是否依赖了 SNAPSHOT 版本的类库
3,代码性能
- 是否有长 SQL 语句
- SQL 语句是否用到索引
- 是否有成熟的类库可以替换自己实现的代码
- 是否可以考虑单例模式
- 是否可以考虑线程池
- 是否可以考虑 NIO
- 是否可以进行锁优化
4,代码注释
- 类及方法是否有注释
- 注释是否可以表达其准确含义
- 在代码中是否存在 FIXME 及 TODO 等注释
- 注释是否包含边界值及对异常情况的说明
5,单元测试
- 代码是否有可测试性
- 新代码是否有单元测试
- 单元测试是否可以覆盖所有场景
6,代码优化
- 是否可以使用枚举代替自定义的常量
- 在代码中是否包含魔法值
- 是否可以使用 Optional 代替 NPE 的检查
- 是否可以使用 Stream 代替 for 循环
- 是否可以使用设计模式
7,其他
- 代码逻辑是否正确
- 是否实现了业务功能
- 代码是否有好的可读性及可测试性
附:代码审查建议
1,不要一次审查太多代码
(1)2006 年 5 月,Smart Bear 针对 Cisco 进行了为期 10 个月的代码审查方面的研究,最终得到一份思科代码审查报告(Code Review at Cisco Systems)。在该报告中指出,做代码审查,每次审查的代码行数最好在 200 行以内,不超过 400 行,否则查找代码缺陷的效果就会大打折扣。
下图展示了一次审查的代码行数和可发现的代码缺陷之间的关系。我们发现,当代码行数超过 200 时,缺陷密度(每千行代码的缺陷数,为缺陷数量与代码行或功能点数量的比值,其测量单位是 defects/KLOC )就会急剧减小,超过 400 后,缺陷密度几乎为 0。

(2)所以,每次代码审查的代码最好在 200 行左右,最多不要超过 400 行,这样更有利于代码审查者集中精力,最好每天都抽出固定的一段时间,来集中精力对少部分代码做代码审查。
2,进行一次代码审查的时间不要太长
除了一次不要审查太多代码, 每次代码审查的时间也不宜过长。研究表明,进行一次代码审查的时长应控制在 90 分钟内,这里建议控制在 60 分钟以内,如果审查时长超过 90 分钟,则代码审查的效率会大大降低。也就是说,虽然花费了更多的时间,但得到了更糟糕的结果。
在进行代码审查之前,应该规划好需要审查的代码长度及时长,尽量控制在 200 行代码、60 分钟左右,这样的效率是最高的。