VE/PUGC CodeReview Guide

Code review 机制

For Committer

为了确保 review 质量,贯彻 lightweight review 原则,一次 CL (或者 MR) 的新增代码行数请控制在 300 行以内,自动生成的代码和 vendor 除外

分支开发时,不要用自己的名字或者缩写来作为分支名。具体规范参考 Branch naming convention

为了确保 Commit Message 的可读性,建议按以下 header+body 的格式编写。(附: Golang 开发 CL 示例)

header

[type]subject

# 几种基本的type

# fix: bugfix

# feat: 新feature

# docs: 修改文档

# test: 修改测试

# refactor: 重构(包含依赖和引用调整)

body (optional, 大型 feature 必须,帮助 reviewer 了解背景和理解代码)

background: 简要介绍背景上下文,必要可以粘贴需求doc链接

howTo: 简要概括你怎么做的和为什么选择这么做

MR 示例:

feat: https://code.gitlab.org/user/potential_relation/merge_requests/2

fix: https://code.gitlab.org/user/potential_relation/merge_requests/4

必要时代码注释要写为什么这么做而不是写做了什么

接入代码静态检查的项目,确保警告全部清除完毕之后再提交 Review

接入了 CI 的项目 (未接入 CI 的项目至少保证自测完备) 需要保证通过了 CI 之后再提交 Review

认真对待 Reviewer 的建议,不一定都要回复,但确保自己准确理解到 Reviewer 的 Comments

对于紧急情况,必要可直接当面沟通

For Reviewer

确保自己准确理解代码的背景和意图,对本次 Change 有足够的Owner意识明确review需要check的要点

对于自己不熟悉的代码,可以主动联系提交者进行沟通或转交他人 review

严格遵照 CheckList 进行 review

对于一些业务紧急改动非常频繁的项目可酌情放宽 review 标准,但对于一些新开发或者重构中的项目必须严格按照标准执行

对于口头沟通过的问题也需要详细写下对应的评论,方面日后总结回顾

Comments 要明确易懂,建议考虑提交者的经验背景调整 comments 详细程度

连续 Review 时间不易过长,建议控制在 60 分钟以内

Review 并不只是为了挑毛病,不要吝啬👍

For Big Change

以上主要是指一般的迭代开发。对于一些大型改动的场景:

在代码开发之前需要写系统设计,并将设计提交 review

必要时可组织系统设计的 review 评审会

将设计拆分成小的 task 后方可启动开发

开发时依照一般迭代的准则进行开发和 CodeReview

Review CheckList

Commit Message是否符合规范,不符合规范的可以拒绝Review

代码否符合规范,风格是否统一 ,建议参考

Python: google-python-styleguide

一次 CL (MR) 是否引入多个的模块的改动

一次 CL 应只包含一个模块逻辑的改动

一个模块的改动是否在一个 commit 内 (便于 revert 和回滚)

代码的可读性和可维护性

代码的逻辑是否清晰

代码设计是否具有可扩展性

代码是否有重复逻辑

代码是否过度设计,引入不必要的复杂度

代码注释是否合理

异常处理是否符合规范

错误返回是否合理

重试是否有可能引发下游雪崩

对特殊关键逻辑是否有对应的降级处理方案

新增接口是否添加接口测试 (Testing/ITC)

新增代码是否有单元测试

单元测试的覆盖率是否足够

接入 CI 可根据单测覆盖率工具判断,如新增代码的单测覆盖率是否 80%+

没有接入 CI 就用肉眼看代码判断🙈

代码的性能是否有问题

明确接口的qps量级

如是否存在 IO 和内存的过度占用(e.g. loop query, db最大连接数设置是否生效等)

是否会引入慢查询导致db hang死

redis是否有可能会引入大key热key

提交的改动是否会影响到现有的上下游服务,设计是否提前周知到上下游业务方

业务日志是否合理,避免重复随意打日志,日志的可读性和可解析性 (json/ltsv)

关键逻辑数据 (如金钱等) 是否有 metrics 和设置相关监控

是否涉及敏感数据,如有必要是否实现加密存储

是否依赖外部配置 (如 tcc),相关配置改动是否同步周知或 review

上线过程中是否有需要特别注意的地方,必要时可 Comment 提醒如:

只先上小流量观察一段时间

某个固定时间节点打开配置开关等

迭代更新中...

值得一读的博文

Code Review Best Practices

https://juejin.im/post/5c9740ba6fb9a071090d6a37

https://coolshell.cn/articles/11432.html


人生有無數種可能,人生有無限的精彩,人生沒有盡頭。一個人只要足夠的愛自己,尊重自己內心的聲音,就算是真正的活著。