Coding Review (代码审查清单)

看过《阿里巴巴编码规范》和《码出高效》两本书后，结合P3C和Sonar在扫描编码规范后，常见的编码错误和安全漏洞就会浮现。为了保证整个团队代码质量，代码审查很有必要。制作一份量身定制审查清单，清单上的任何条目都必须明确，让团队记录在代码审查工程中发现问题，解决问题。这可以帮助你提高代码标准，避免质量参差不齐的代码审查。清单故意没有详尽的列出，太长了以至于从来没人会去用它，仅仅包含常见的问题会比较好。

常规项

1.代码是否可以运行

2.它有没有实现预期的功能

3.逻辑是否正确

4.所有的代码是否简单易懂

5.代码符合你所遵循的编程规范么？（大括号的位置，变量名和函数名，初始化，行的长度，缩进，魔法值，格式和注释）

6.是否存在多余的或是重复的代码

7.代码是否尽可能的模块化了

8.是否有可以被替换的全局变量

9.是否有被注释掉的代码

10.循环是否设置了长度和正确的终止条件

11.是否有可以被库函数替代的代码

12.是否有可以删除的日志或调试代码

13.是否有可以异常处理环节

14.是否考虑提示信息

15.常量是否放在常量类

安全

1.所有的数据输入是否都进行了检查（类型，长度，格式和范围）并且进行了编码

2.在哪里使用了第三方工具，返回的错误是否被捕获

3.输出的值是否进行了检查并且编码

4.无效的参数值是否能够处理

5.是否安全地处理和存储了敏感数据，例如用户数据

6.授权和认证是否加密

7.是否解决了跨站点脚本，SQL注入等安全漏洞

文档

1.是否有注释，并且描述了代码的意图（创建人、创建时间、返回值、参数、异常说明外，该方法做了什么事情，实现了什么功能）

2.所有的函数都有注释吗

3.对非常规行为和边界情况处理是否有描述

4.第三方库的使用和函数是否有文档

5.数据结构和计量单位是否进行了解释

6.是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’

测试

1.代码是否可以测试？不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。

2.是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖。

3.单元测试是否真正的测试了代码是否可以完成预期的功能

4.是否检查了数组的“越界“错误

5.是否有可以被已经存在的API所替代的测试代码

SQL

1.是否符合建表规约

2.是否实体属性与表结构一一对应

3.是否可以避免全表查询

4.条件查询是否需要建立索引

5.主键、外键是否需要建立索引

6.建表是否需要五要素（创建人、创建时间、修改人、修改时间、备注）

方案

1.一个方案是否可以解决一个主要问题

2.评估方案是否可落地（评估技术实现、研发时间、成本效益等）

3.是否引入新组件

4.方案是否有拓展性

5.方案施行是否资源投入充足

设计

1.设计图是否充分体现需求

2.设计图是否看懂

3.是否遵循已有规范和架构

4.是否考虑遗留接口

5.是否考虑历史数据

6.是否流程可以并行和回退

7.是否可以降低复杂性（调用链路过长、程序策略复杂无法落地、跨库、跨存储、使用缓存、使用异步）

服务

1.是否需要更多资源（突发流量、定时任务、多线程、缓存机制等）

2.是否考虑服务降级或升级处理（负载均衡、升级扩容，降级限流）

数据

1.是否组件挂掉导致数据不一致

2.是否可以记录冗余数据弥补数据丢失

资源

1.是否协调部门资源

2.是否估计部门大体工作量的程度

风险

1.是否有技术难点（应用组件、复杂流程、集成规约）

2.是否有业务风险（法律法规、敏感信息、歧义交叉）

备注

1.通用法则，与团队分享清单

2.编码规约，不约而同

3.不囤积警告，不推迟修复，保持整洁，保持高效

4.技术有情，代码有爱，伯牙子期，琴瑟和鸣