数栈项目的 Code Review 实践小结

DTUX - 小威

项目背景

数栈是一个由多个独立子应用组合的平台产品

已完成 5 个

废弃 1个

正在开发 1个

小威

饮冰

小志、小康

鱼人

修能

青忆、古一

相继8位不同背景的同学贡献过代码

835个文件

13W+行代码

问题

• 已完成的功能模块经常容易改出新问题
• 重复的API, 模块封装
• 奇怪的框架使用方法
• 代码质量参差不齐
• 闷头开发，对彼此的工作（代码）并不熟悉，缺少交流

思考

Code Review

非正式代码审查

正式代码审查

阻碍&疑虑

• 迭代节奏紧迫
• 需求变更频繁
• 形式主义，增加工作量，没有太大意义

形式主义？

姿势不对

让阅读代码成为你工作的一部分，而不是仅仅闷头码代码！

利用 Gitlab 做 Code Review

常见的一些 reivew 工具

• Phabircator （Facebook)
• Gerrit (Google)
• Gitlab / Github
• ...

Gitlab Code Review 基本流程

为了默契，开展这项活动前，我们需要一些规则

Merge Request 注意项

Reviewer 注意项

• 保持独立的 feature, bugfix、refactor作为分支进行MR
• 提交的 commit 需要是有意义的描述，并带上响应的 issue ID
• 复杂的MR内容，必要情况需添加 description 内容
• MR 紧急，可以线下通知 Reviewers

• 指定模块最近参与修改的单个或多个同学作为 Reviewer
• 指定参与相关模块讨论和 Desgin 过的人 Review
• 项目核心开发者
• 如有必要 reviewer 可分配给其他相关人

制定CheckList，并不断完善

CheckList

• 错误、重复的 API 调用或者封装
• 配置、接口类的设计问题（合理性、友好性）
• 架构类问题（业务/技术）
• 功能，逻辑的遗漏缺陷
• 是否清理无用的注释代码
• 变量、模块的命名的可维护性、可读性等
• 是否缺少应有的单元测试或者文档
• 页面展示类的 review, 时间允许最好在浏览器检查

配合工具更佳

• ESLint 代码静态检测, 解决基本的代码风格不统一的问题，避免一些低级bug。当然ESLint最好集成到 dev 构建环节中去
• GitLens 非常好的 git 可视化管理插件
• Gitlab MR 协助快速创建MR请求

总结

作为一个长期维护的商业软件

瀑布模型

敏捷开发
极限编程

缺陷检测率

截止3月底

• 约 350 + 次 merge
• 约 90 + 次 comment
• 平均每次 MR 会产生 0.25 次讨论

直接体会

• 代码质量明显提升

• Bug检出率没那么明显

提升质量，还能做些什么？

• 提升 Review 质量
• 提升 PRD 评审质量，自动化测试

提升质量需要的是组合拳

最后，