开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第8天，点击查看活动详情
众所周知，越来越多的大厂开始推广并强调代码评审(Code Review)，为了团队成员相互学习，使团队成员的代码更加健壮，提早发现代码缺陷。今天我们就来简要介绍一下，在devops环节中开始出现的code review
代码评审(Code Review)有一些好处：
- 提升系统的可维护性，发现潜在缺陷与BUG
- 促进团队内部知识共享，提高团队整体水平
对于评审人员来说，也是一种思路重新组装的过程。日常交叉审查代码方便熟悉对方模块业务，对于团队来说，也可以降低因人员流失的运营成本及风险
当然，避免不了的就是会增加一些工作量和工作时间，去review大家的代码，但用到实处，是利大于弊的
那么该怎么做呢？
- 提交者每次提交最好是一个完整的功能，便于完整理解所有逻辑（实际上日常可能会较低可能性）。交代清楚填写代码说明/Reviewer/产品链接
- Reviewer查看审查任务，进行代码评审（一些基本的规范可以通过工具在在控制，例如自动审核）
- Reviewer根据团队（代码规范去评审一些代码，然后给出通过或者不通过的决定
- 修改，重审
- 代码通过，合并分支
一些需要关注的地方：
1.Code Review有规范的时间和要求，审查追求的是质量，希望有团队共识
2.可以使用一些Code Review工具，在devOps全家桶中也越发常见。例如：www.gerritcodereview.com/
写在最后
重新开始更文啦！最近因为工作原因，一直在学习devops的内容，感谢大家的支持！我会继续努力坚持学习！养成了好习惯，每天必定会抽出时间多多少少学习技术知识～
以上习题&笔记从大佬们的论坛学习而来，特感谢大佬们的知识分享～ （学习技术知识，果然要看大佬们的技术博客，大家有好的推荐也欢迎指引我这个小白哈，感恩！）
