数栈项目的 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 评审质量,自动化测试

提升质量需要的是组合拳

最后,

数栈项目的 Code Review 小结

By Ziv 小威

数栈项目的 Code Review 小结

  • 232
Loading comments...

More from Ziv 小威