代码审查

代码审查：

一种有效帮助提升代码质量的有效途径。

• 代码审查3W(what why when)
• 常见的代码审查工具
• 代码审查流程

1.代码审查3W(what why when)：

代码审查：对计算机源代码系统化的审查，常用软件同行评审的方式进行，目的是找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。

1.1 why:

帮助提升代码质量、上下文共享、帮助新人快速融入项目、帮助开发人员成长、帮助在项目中的影响力建设

代价：

• 专门的时间和精力：选择合适的代码审查方式
• 可能引起团队成员间的不适：沟通技巧，正向反馈等

1.2 when:

有代码变更就可以进行代码审查：

• 已提交到远程仓库
• 未提交到远程仓库

代码审查频率和形式：

• 异步式：借助一些工具随时进行。

2.常见的代码审查工具

代码审查的对象是源代码：不是整个系统的源代码，针对改动的代码进行审查即可。

工具：

• git
• svn
• Gerrit
• UP(jetbrains)

工具应该可以显示代码变更、使用源码仓库、在线代码讨论、异步审查支持、使用协议(开源协议)等

3.代码审查流程

3.1 范根检查法：

规划(选择需要参加的成员，准备物料，安排会议)——-》概述(针对需要审查的项目和代码做简要的描述，并分配参与人员的角色)——》准备(准备参与者需要审查浏览的项目，记录下发现的问题和疑问，为自己的角色做好准备)——–》审查会议(参与者一起探讨需要重新检查的项目，以便真正发现错误)——-》调整和修复—–》重新规划和代码审查—->不重要的修复则修复后直接进入“跟进”，在跟进环节里验证修复是有效的。

3.2 轻量级的审查流程：

• 结对编程:直接和代码审查者进行结对编程，编码过程中，审查者就会对代码进行审查并提出相关的建议。
• 同步代码审查：编码完成后立即或在有效的时间段内，找到审查者和代码进行审查。
• 异步代码审查：借助工具发起代码请求，可以等待审查结果。

如何进行代码审查：

• 编码风格
• 命名规范
• 功能性
• 测试覆盖
• 复杂度
• 注释
• 设计
• 安全

让代码审查更高效。

 1.编码风格

• 命名风格：

不以下划线或美元符 开头或结束；类名UpperCamelCase；方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，

常量命名使用全大写，单词间用下划线分隔；包名统一使用小写；禁止拼音命名；

• 常量定义：禁止未定义的常量；长整型赋值需要使用大写L后缀；变量值可穷举，考虑使用枚举；
• 代码格式: 采用4个空格的缩进，禁止使用tab字符；单行字符限制不超过120个；换行符使用unix格式；运算符左右2边都需要加上1个空格；保留字和括 之间都必须需要空格；多个参数逗 后都需要加空格；左大括 前不换行，左大括 后换行；右大括 前换行，终止的右大括 后换行；
• OOP规约：面向对象规约；静态方法/变量使用类名访问；复写方法需要@Override；禁止过时的方法/类的使用@Deprecated；包装类型的比较使用equals()；
• 分支控制： switch中，每个case必须使用continue/break/return终止或注释说明到哪个case终止；switch需要对字符串判空；分支逻辑使用大括 ；
• 注释：类/方法注释使用javadoc规范；方法内部单行注释，使用//在需要被注释的语句上方单起一行；无用代码删除，而不是注释；

工具：通过一些plugins。例如Alibaba Java Coding Guidelines、Gradle插件checkStyle、

 2.命名规范

• 足够长以揭示意图，又不太长难以阅读
• 使用有意义的名字
• 范围越大，命名越长；范围越小，命名越短；
• 避免使用非约性缩写
• 使用自然语言命名：如英语
• 使用对应领域的专业名称：如算法名称
• 不好命名，考虑类、方法职责过多，是否需要拆分重构
• 一致性

3.功能性

• 代码是否符合用户意图：真实用户、开发者

功能性验证维度：

• 输入输出、流程是否正确
• 边界是否考虑并处理得当
• 是否高并发的安全问题

4.测试覆盖

软件测试：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

自动化测试的必要性：测试时间会占用总开发时间的20%~40%，一些可靠性要求非常高的软件，测试时间甚至要占用总开发时间的60%。

测试金字塔：

集成度越高的测试，速度越慢。

 测试覆盖率：JACOCO工具

5.复杂度

复杂度高的话：

• 可读性降低
• 可维护性降低
• 缺陷概率高
• 模块内聚性低

复杂度度量：圈复杂度(V(G)=判定节点数+1)

复杂度优化：

• 方法抽取
• 反向表达
• 单一职责
• 使用多态

6.注释

• 帮助正确使用(README.md文件等)
• 好的代码即注释，但是代码再可读也不及自然语言。
• 对外、公共的接口，模块、系统描述，宁缺毋滥等需要写注释

7.设计

• 提升系统稳健性
• 提升可读性/可维护性
• 提升可扩展性

设计维度审查：

• 是否足够解耦
• 是否可以使用一些设计模式
• 是否可以应对一些变化
• 是否过度设计

8.安全

安全性低带来的问题：

• 数据容易泄露
• 程序运行异常
• 资源消耗异常

安全维度审查：

• 源码库是否包含凭据
• 敏感数据是否加密落库
• 输出是否安全
• 输入是否安全
• 权限管控是否正确
• 返回值谨慎使用null

自动化安全审查工具：

• sqlmap:sql注入的检测
• owasp:针对依赖进行安全检测
• WebCruiser:检测sql注入和web系统的其他漏洞

被审查者：

• 变更描述要足够清楚
• 单次改动不要过大
• 积极接受反馈

审查代码者：

• 要有度量标准
• 审查速度
• 给予良好的反馈