Code Review的目的
Code Review应该是软件开发团队“共同学习、识别模式和每日持续”的过程，而不是带有“审、查、评”等令人感到紧张气氛的过程。
把Code Review称作“代码回顾”吧，而不要称作令人紧张的“代码评审”或“代码走查”，把它打造成软件开发团队“共同学习、识别模式和每日持续”的过程，来有效提升团队代码内在质量。
如何进行Code Review
- 一对一评审
提交的merge request 不要超过2天的工作量
无论何时你发起了一个关于 6 行代码的评审请求，你总会得到很多同事关于这 6 行代码的指指点点。但当你 push 了一个花了几周时间的代码分支，你常常会得到一个很快回复的：LGTM!（Looks Good To Me）
- 团队评审会议
每周一次（或者每个迭代一次），时间控制在60~90分钟
提交Merge Request的格式
用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述：
你改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。
特别需要留意，如果对基础、公共的组件进行了改动，一定要另起一行特别说明。
注意事项
- 尽早的进行评审，不单是代码评审，复杂的故事需要提前进行方案评审
- 每次Review的代码不要超过两天的工作量（大的故事开独立的feature分支，各个开发基于这个feature分支进行开发；小的故事直接基于develop分支进行开发）
- 每次Review时间不要超过90分钟
- 发现问题并能够给出问题的解决方案
- 每次Review不要超过500行代码
check list
- 代码格式
- 代码可读性
- 有没有漏掉重要的case
- 测试用例和防坑
- 异常处理
- 工程结构
参考
https://juejin.im/post/5a24ed34518825619a028484
https://gitmoji.carloscuesta.me/
http://insights.thoughtworkers.org/code-review/
网友评论