如何做且做好代码审查
代码审查
代码审查（code review）是我们保障代码质量的重要一环，我们通过代码审查者对代码的走查、评论、修复的循环流程，保障CR的有效性
如何发起代码审查
通常我们都是基于git来做代码审查， 当我们开发一个功能时，可以针对当前的工作分支，发起一个merge request， 并指定相关的同学进行代码审查
通常情况下， 我们带去审查的时间并不固定，从我们的第一次commit开始，其实就可以发起cr了
对于大型的需求或项目，我们强烈建议，分步提交，及时CR，最终再合并commit
同时审查方式也分
- 线下审查会议： 针对大型需求或项目，有一个集中的会议，由发起人讲述，参会人review
- 快速审查方式：小型需求，可参与快速审查的方式，可以面对面讲解或线上review+反馈
如何做代码审查
-
检查前置的准备工作是否ok
如：技术文档是否编写并完善 -
检查CR的标题和commit内容是否完善
commit的内容，需要简明扼要的描述改动的目的和方式，便于review的同学快速知晓 -
关注整体设计
- 功能实现的方案是否符合现有的系统设计
- 代码的层次和交互是否有意义
- 代码风格是否满足当前的团队规范
-
关注细节实现
我们应该要对当前代码diff出的任何一行进行review， 不能假定某行代码就没有问题
- 注释： 是否有合适的注释
- 命名：一个好的命名有助于我们快速了解函数的功能， 当前我们审查的一个关键也是函数的功能是否匹配了命名！
- 是否存在重复：存在两个以上功能相似的函数或UI模块
- 是否存在过度设计：是否实现了未来可能要支持的功能
- 是否存在一些边界问题： 如常见的undifined问题
- 是否可读性太差：有时候我们会在代码中使用一些花哨的写法， 在团队合作的项目中这种方式是极度不提倡的。 如果你的初衷是想使代码更简洁，那请在编译过程中处理
-
关注质量保障
如果我们本次的代码涉及到一些重大的改动或有需要执行质量保障相关的动作， 那我们有必要提醒相关同学- 是否执行了自测和单测
- 是否执行了接口diff (如需)
- 是否执行了数据库diff (如需)
如何编写合适的comment
我们站在共同维护和提升团队代码的前提下， 我们明确CR的comment需要
- 保持友善的态度。 代码的实现可能是由于技术或者外因导致， reviewer可以给出建议，并与相关同学积极讨论，共同拿出一个合适的方案
- 解释你的建议或问题： reviewer不应该只是指出问题， 需要加上一些自己的判断原则或来源
- comment应该足够明确： reviewer需要写明自己的方案或指出问题，由开发者自己决定后续采纳方式
- 不要吝啬赞美：毫无疑问，我们在平时工作中除了看到烂代码，也会看到实现优雅的代码，这时候请及时赞美和分享哦
扩展
上述的过程是我们一个CR的通用流程和方式， 那么我们还应该做些什么来辅助和减轻CR的压力呢
-
明确CR的准入规则
即我们什么样的commit才能够进入到代码审查的环节
- 代码需要通过code lint (git commit hooks)
- 代码需要通过编译！有时候我们会偷懒的认为自己的代码一定没有问题而忽略了一些必要的阶段
- 代码通过了单测（该部分是前端欠缺较多的，但是的确很重要）
-
优雅的系统架构，可以帮助我们快速实现和降低review的成本
这个部分依赖于大家对系统的初始设计和后期的持续优化。 如果是一个历史包袱很多的系统，那CR带来的效果甚微， 我们就需要先解决代码设计的问题哦！