让美的事情发生
Ziv小威
数栈前端项目的 Code Review 实践小结

背景

近两年我都在同一个项目上共献代码,算起来这算是我参与过最大的前端项目了。项目最开始只有我一个人做编码工作,后来陆陆续续一共有 8 个同学给项目贡献过代码,到现在稳定在 4 个人都在同时给项目提交代码。参与的同学有经验丰富一些的,也有工作一两年的小伙伴,还有实习的同学。

cloc-codes

两年多的时间里,我一直在间接的接手或者被接手彼此同伴的代码。 由于早期同时参与的时候最多也就 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 基本流程

codereview workflow

这也是从参考社区后指定的一个流程,目前其中的自动化 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)的迭代方法,还是当下使用最多的敏捷开发,代码审查都是很重要的一环。

the check rate of bugs

我大概统计了下,截止 3 月底,数栈项目进行了约 350 + 次 merge 操作,有记录的 comment 约 90 + 次,我计算了下,平均每次 MR 操作约会产生 0.25 次交流。这个数值应该不算高。后来大家总结下来跟我们的预期有一些差别,例如检出 Bug 的概率不高,检出的 Bug 也都是比较明显,能一眼看出的,当然这可能跟我们评审质量有关系。最明显就是代码质量的的改善了,像重复、遗漏、可读性等问题都很明显的改善。

总而言之,大家总结下来结果对 codereview 这个环境还是比较满意的,当然还有很多不足点需要改善。想减少产品缺陷光靠代码审查一个环节显然是不足够的,正如上图(图 2)所示,我们必须在构建各个环节上做出相应的措施,最终才可能得到比较满意的结果。


最后修改于 2019-04-12

Comments powered by Disqus