Ziv小威

数栈前端项目的 Code Review 实践小结

Ziv小威 发表于2019-04-11 前端工程化

背景

这是一个持续了近两年多时间的项目,项目由最开始只有我一个人,到后来陆陆续续一共有 8 个同学先后给项目贡献过代码。如今代码量已经达到了近 13W+ 行代码,算的上是个不小的前端项目了。

cloc-codes

两年多的时间里,大家都是间接的接手或者被接手彼此的代码。 由于早期同时参与的时候最多也就 2 个同学,Code Review 这种事情似乎就显得多余了。不过在大概过了一年多之后,项目业务复杂度和代码量已经达到了一定规模,而此时已经有 5,6 个不同工作背景的同学参与过这个项目了。此时项目逐渐暴露出来一些工程问题摆在眼前:

Code Review 的阻碍 & 疑虑

由于之前了解到的 Code Review 的信息都是比较负面的,所以在团队准备开始加上这个环节时还是有很多疑虑的:

通过在网上搜索相关信息,我发现大家遇到的问题和疑虑无外乎这么几点。很多团队的项目时间都非常紧张,功能都做不完,感觉代码审查太浪费时间了。还有很多的情况是做着做着就沦为了形式主义, 我搜索资料是这方面的声音比较多。

在我查资料的过程中,我去参考了一些知名的开源项目。最后总结下来,其实增加 Code Review 并不会占用太多的时间(当然也有需要投入较多时间的情况),另外大部分的 Code Review 最终沦为了一种形式,这主要还是因为姿势不对的原因,短期看不到收益,很难坚持。

利用 Gitlab 做 Code Review

Code Review 作为一项十分成熟的软件构建环节,自然会配套十分成熟 的工具。通过工具可以大大的提升 review 效率和质量。我在网上搜索了下,这方面的工具还是非常多的,下面是我列举的几个比较常见的:

常见的一些 Review 工具

考虑到我们团队本身在使用 gitlab,索性我们就选择 gitlab 作为工具先试试了。通过 Merge request 功能,我们可以方便的添加 Code Review 环节开发流程。在我们熟知的 Github 中则是 pull request。目前我们的 Code Review 基本流程大致如下:

codereview workflow

(图片-1)CR 基本流程

这也是从参考社区后制定的一个流程,目前其中的自动化 CI 工具我们还没打通。为了更顺利默契的进行这个环节,我们需要制定一个基础的规范:

MR 注意项
Reviewer 相关
CheckList

当然上面列举的规则,随着认知的提升可以不断的完善更新。

配合工具更佳

为了提升工作效率,我们可以在我们的 IDE 工具中安装相关的各种插件,提升整个 Review 效率,由于我们大部分同学都在使用 VSCode,这里我就列举部分插件以作参考:

总结

作为一个需要长期维护的商业软件,并在可预见的范围内,项目仍然有很长的成长空间的情况来下,增加代码审查环节是十分有必要的。无论是在传统的瀑布模型(Waterfall Model)的迭代方法,还是当下最多的敏捷开发,代码审查都是很重要的一环。在《代码大全》讨论质量提升的章节中有个统计,显示代码审查缺陷检出率还是非常高的:

the check rate of bugs

(图片-2)来自代码大全

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

总而言之,大家总结下来结果对 Code Review 这个环节感觉还是很有意义的,当然还有很多不足点需要改善,例如提升 Review 质量,定期总结等等。

Ziv小威 · 前端工程化

让美的事情发生

 
comments powered by Disqus