代码审查：
一种有效帮助提升代码质量的有效途径。
- 代码审查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系统的其他漏洞
被审查者：
- 变更描述要足够清楚
- 单次改动不要过大
- 积极接受反馈
审查代码者：
- 要有度量标准
- 审查速度
- 给予良好的反馈
