背景
近两年我都在同一个项目上共献代码，算起来这算是我参与过最大的前端项目了。项目最开始只有我一个人做编码工作，后来陆陆续续一共有 8 个同学给项目贡献过代码，到现在稳定在 4 个人都在同时给项目提交代码。参与的同学有经验丰富一些的，也有工作一两年的小伙伴，还有实习的同学。
两年多的时间里，我一直在间接的接手或者被接手彼此同伴的代码。 由于早期同时参与的时候最多也就 2 个同学，所以项目一开始并没有 CodeReview，大概过了一年多后，项目代码量已经达到了一定规模，业务逻辑也有了较大的积累了，此时已经有 5，6 个同学参与过这个项目了。这期间逐渐暴露出来一些问题摆在眼前：
- 已完成的功能模块经常容易改出新问题
- 重复的 API, 模块封装
- 奇怪的框架使用方法
- 代码质量参差不齐
- 闷头开发，对彼此的工作（代码）并不熟悉，缺少交流
阻碍&疑虑
- 迭代节奏紧迫（时间担忧）
- 需求变更频繁
- 形式主义，增加工作量，没有太大意义
其实一开始我自己也有这些潜意识的疑虑，项目时间这么紧，都做不完，还做代码审查。后来我去查了下资料，然后参考了一些开源项目的 review 情况。最后总结下来，其实增加 code review 并不会占用太多的时间（当然也有需要投入较多时间的情况），另外大部分的 code review 沦为了一种形式，没有达到应有的效果，这主要还是因为姿势不对的原因。
利用 Gitlab 做 Code Review
code review 作为一项十分成熟的软件构建环节，自然会配套十分成熟 的 review 工具。通过工具可以大大提供 review 效率和质量。
常见的一些 reivew 工具
- Phabircator （Facebook)
- Gerrit (Google)
- Gitlab / Github
- …
考虑到公司本身在使用 gitlab，索性我们就选择 gitlab 作为工具，采用基于 Merge request 的 code review 流程了，而在我们熟知的 Github 中则是 pull request。
Gitlab Code Review 基本流程
这也是从参考社区后指定的一个流程，目前其中的自动化 CI 工具我们还没打通。为了更顺利默契的进行这个环境，我们还是指定了一个基础的规范，主要包含 reviewer 和 checklist 两个部分：
MR 注意项
- 保持独立的 feature, bugfix、refactor 作为分支进行 MR
- 提交的 commit 需要是有意义的描述，并带上响应的 issue ID
- 复杂的 MR 内容，必要情况需添加 description 内容
- MR 紧急，可以线下通知 Reviewers
Reviewer 注意项
- 指定模块最近参与修改的单个或多个同学作为 Reviewer
- 指定参与相关模块讨论和 Desgin 过的人 Review
- 项目核心开发者
- 如有必要 reviewer 可分配给其他相关人
CheckList
- 错误、重复的 API 调用或者封装
- 配置、接口类的设计问题（合理性、友好性）
- 架构类问题（业务/技术）
- 功能，逻辑的遗漏缺陷
- 是否清理无用的注释代码
- 变量、模块的命名的可维护性、可读性等
- 是否缺少应有的单元测试或者文档
- 页面展示类的 review, 时间允许最好在浏览器检查
当然上面列举的一些规则，随着不断的认知可以完善更新。
配合工具更佳
为了提升工作效率，我们可以在我们的 IDE 工具中安装相关的各种插件，提升整个 Review 效率，由于我们大部分同学都在使用 VSCode，这里我就列举部分插件以作参考：
- ESLint 代码静态检测, 解决基本的代码风格不统一的问题，避免一些低级 bug。当然 ESLint 最好集成到 dev 构建环节中去
- GitLens 非常好的 git 可视化管理插件
- Gitlab MR 协助快速创建 MR 请求
总结
作为一个需要长期维护的商业软件，并在可预见的范围内，项目仍然有很长的成长空间的情况来下，这些问题无疑会使眼下这条路走得不轻松。无论是在传统的瀑布模型（Waterfall Model）的迭代方法，还是当下使用最多的敏捷开发，代码审查都是很重要的一环。
我大概统计了下，截止 3 月底，数栈项目进行了约 350 + 次 merge 操作，有记录的 comment 约 90 + 次，我计算了下，平均每次 MR 操作约会产生 0.25 次交流。这个数值应该不算高。后来大家总结下来跟我们的预期有一些差别，例如检出 Bug 的概率不高，检出的 Bug 也都是比较明显，能一眼看出的，当然这可能跟我们评审质量有关系。最明显就是代码质量的的改善了，像重复、遗漏、可读性等问题都很明显的改善。
总而言之，大家总结下来结果对 codereview 这个环境还是比较满意的，当然还有很多不足点需要改善。想减少产品缺陷光靠代码审查一个环节显然是不足够的，正如上图（图 2）所示，我们必须在构建各个环节上做出相应的措施，最终才可能得到比较满意的结果。
最后修改于 2019-04-12