代码审查（文档整理）

• 常用的代码审查工具

	git/SUBVERSION	Gerrit	Upsource
显示代码变更	√	√	√
使用源码仓库	√		√
在线代码讨论		√	√
异步审查支持		√	√
使用协议	GPLv2/Apache License 2.0	Apache License 2.0	付费license

• 代码审查
  • 范根检查法
    
  • 轻量级的审查流程
    • 结对编程
    • 同步代码审查
    • 异步代码审查
  • 代码审查需要关注什么
    • 编码风格
    • 命名规范
    • 功能性
    • 测试覆盖
    • 复杂度
    • 注释
    • 设计
    • 安全性

如何做代码审查

编码风格

命名风格

1. 不以下划线或美元符号开头或结束
2. 类名UpperCamelCase
3. 方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格
4. 常量命名使用全大写，单词间用下划线分隔
5. 包名统一使用小写
6. 禁止拼音命名
7. 禁止不规范的缩写

常量定义

1. 禁止未定义的常量
2. 长整型赋值需要使用大写L后缀
3. 变量值可穷举，考虑使用枚举

代码格式

1. 采用4个空格缩进，禁止使用tab字符
2. 单行字符数限制不超过120个
3. 换行符使用unix格式
4. 运算符的左右两边都需要加一个空格
5. 保留字与括号之间都需要加空格
6. 多个参数逗号后需要加空格
7. 左大括号前不换行，右大括号后换行；右大括号前换行，终止的右大括号后换行

OOP规约

1. 静态方法/变量使用类名访问
2. 复写方法增加@Override
3. 禁止过时方法/类的使用（@Deprecated）
4. 包装类型比较使用equals方法

分支控制

1. switch中，每个case必须使用continue/break/return终止或者注释说明到那个case终止
2. switch需要对字符串判空
3. 分支逻辑使用大括号

注释

1. 类/方法注释使用javadoc规范
2. 方法内部单行注释，使用//  在需要被注释的语句上方单起一行
3. 无用代码删除，而不是注释

注： 可以使用Alibaba Java Coding Guidenlines 插件进行规约扫描， 或者在Gradle中使用checkstyle插件

一、命名

足够长以结石意图，但又不太长难以阅读。

命名

1. 使用有意义的名字
2. 范围越大，命名越长
3. 范围越小，命名越短
4. 避免使用非约定的缩写
5. 使用一种自然语言来命名，比如英语
6. 使用对应领域的专业名称，比如算法名称等
7. 不好命名，考虑类，方法职责过多，是否需要拆分重构
8. **一致性**

二、功能性

代码是否符合用户（真实用户，开发者）意图

功能性验证纬度

1. 输入输出、流程是否正确
2. 边界是否考虑并处理妥当
3. 是否有高并发的安全问题

三、测试覆盖

在规定的条件下对程序进行操作，以发现程序错误，衡量软件增量，并对其是否能满足设计要求进行评估的过程。
测试时间会占到总开发时间的20%~40%，一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60%。

测试金字塔

测试覆盖率

1. JACOCO

四、复杂度

复杂度高的问题

1. 可读性降低
2. 可维护性降低
3. 缺陷概率高
4. 模块内聚性低

复杂度度量

圈复杂度
V(G) = 判断节点数 + 1

复杂度优化

1. 方法抽取
2. 方向表达
3. 单一职责
4. 使用多态

五、注释

为什么注释？

1. 帮助理解作者意图
2. 帮助我们正确使用

好的代码无需注释？

1. 代码即注释
2. 代码再可读也不及自然语言

注释写到何种程度？

1. 对外、公共的接口
2. 模块、系统描述
3. 宁缺毋滥

六、设计

为什么要审查设计

1. 提升系统稳健性
2. 提升可读性/可维护性
3. 提升可扩展性

设计纬度需要审查什么

1. 是否足够解耦
2. 是否可以使用一些设计模式
3. 是否可以应对一些变化
4. 是否过度设计

七、安全

安全性低有什么问题

1. 数据易泄漏
2. 程序运行异常
3. 资源消耗异常

安全纬度需要审查什么

1. 源码库是否包含凭据
2. 敏感数据是否加密落库
3. 输出是否安全
4. 输入是否安全合法
5. 权限管控是否准确
6. 返回值谨慎使用null

自动化工具

1. sqlmap （sql注入检测）
2. owasp （依赖安全检测）
3. WebCruiser （Web检测工具，sql注入、web系统其他漏洞）

如何让代码审核更加高效

被审查代码作者

1. 变更描述要足够清楚
2. 单次改动不要过大
3. 积极接收反馈

审查代码者

1. 度量标准
2. 审查速度
3. 给予良好的反馈

整理来自：https://www.imooc.com/learn/1225