怎么做好Code Review?

团队为什么要做好Code Review？

一、Code Review的好处

❝

Code Reviewa可以保证项目质量，推升团队技术水平

❞

想要做好Code Review，必须让参与的工程师充分认识到Code Review的好处

• 1、互相学习，彼此成就

• 2、知识共享，自动互备

• 3、统一风格，提升质量

二、推动Code Review落地执行

1、选定工具

可以用来做Code Review的工具很多，这里主要介绍相对主流的Gerrit、GitLab

Gerrit

❝

Gerrit是Google开源的代码审查工具，Gerrit也是一个基于Git构建的版本管理工具，Gerrit支持将其他Git仓库的代码跟Gerrit自己的仓库做同步。所有的代码审查的操作以及权限控制都是在Gerrit自己的仓库上进行的。

❞

GitLab家族

❝

GitLab是基于Git构建的源代码管理系统，基于GitLab构建的 GitLab.com 是仅次于 GitHub.com 的在线源代码管理平台。

❞

2、制定开发规范

❝

没有规则，就没有执行。规则中首当其冲的就是开发规范。

❞

规范中建议包含：

• 工程规范（工程结构，分层方式及命名等等）

• 命名规范（接口、类、方法名、变量名等）

• 代码格式（括号、空格、换行、缩进等）

• 注释规范（规定必要的注释）

• 日志规范（合理的记录必要的日志）

• 各种推荐与不推荐的代码示例

3.制定流程规范

• 确定Code Review实施环节

• 确定Code Review实施环节

code review 行话

❝

最后分享下code review 行话

❞

简称	全称（解释）
LGTM	Looks Good To Me「对我来说，还不错」表示认可这次PR，同意merge合并代码到远程仓库
ASAP	As Soon As Possible「尽快」
ACK	Acknowledgement「承认，确认，同意」i.e. agreed/accepted change
NACK/NAK	Negative acknowledgement「不同意」 i.e. disagree with change and/or concept
RFC	Request For Comments「请求进行讨论」 i.e. I think this is a good idea, lets discuss
WIP	Work In Progress 「进展中」常见词汇，这里作为 Best Practice 单独提出来，主要针对改动较多的 PR，可以先提交部分，标题或 Tag 加上 WIP，表示尚未完成，这样别人可以先 review 已提交的部分
AFAIK/AFAICT	As Far As I Know / Can Tell 「据我所知；就我所知」
IIRC	If I Recall Correctly「如果我没有记错的话」
IANAL	I am not a lawyer , but I smell licensing issues「-」
IMO	In My Opinion 「在我看来」
TL;DR	Too Long; Didn’t Read 「太长懒得看」README 文档常见。
PR	Pull Request「合并请求」
CR	Code Review 「代码审查」
PTAL	Please Take A Look.「你来瞅瞅？」用来提示别人来看一下
TBR	To Be Reviewed「提示维护者进行 review」
TBD	To Be Done(or Defined/Discussed/Decided/Determined). 「未完成，将被做」根据语境不同意义有所区别，但一般都是还没搞定的意思。
TBH	To Be Honest 「老实说」
atm	at the moment 「现阶段」