怎么做好Code Review?
前端壹栈
共 1646字，需浏览 4分钟
·
2021-09-05 16:48
团队为什么要做好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 「现阶段」 |
评论