怎么做好Code Review?-技术圈

怎么做好Code Review?

共 1646字，需浏览 4分钟

· 2021-09-05

团队为什么要做好Code Review？

一、Code Review的好处

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

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

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

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

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

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

规范中建议包含：

❝
最后分享下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 「现阶段」