数栈项目的 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, 时间允许最好在浏览器检查
配合工具更佳
总结
作为一个长期维护的商业软件
瀑布模型
敏捷开发
极限编程
缺陷检测率
截止3月底
- 约 350 + 次 merge
- 约 90 + 次 comment
- 平均每次 MR 会产生 0.25 次讨论
直接体会
-
代码质量明显提升
-
Bug检出率没那么明显
提升质量，还能做些什么？
- 提升 Review 质量
- 提升 PRD 评审质量，自动化测试