什么是代码审查？ (What are Code Reviews?)

A Code Review is essentially what it sounds like: a review of code before it is approved/accepted into the codebase. The general flow goes like this; an engineer writes some code in order to fix a bug/address some item of work. The engineer sends out a Code Review/Pull Request, basically asking for their changes to be accepted into the main body of project. One or more other engineers review the code changes, leaving comments/feedback, and either approves or rejects the changes. Rejection is often a temporary state asking for the comments/feedback to be addressed and the updated changes submitted again for approval.

本质上，代码审查听起来像是：在批准/接受代码库之前对代码进行审查。 总体流程如下： 工程师编写一些代码来修复错误/解决某些工作。 工程师发出一个“代码审查/拉取请求”，基本上是要求他们的更改被接受到项目主体中。 一个或多个其他工程师检查代码更改，留下评论/反馈，然后批准或拒绝更改。 拒绝通常是一种临时状态，要求处理评论/反馈，并再次提交更新的更改以供批准。

The idea of this flow is to ensure that code entering the project meets a variety of expectations and standards, enforced by everyone on the team. The requirements being enforced often include coding style standards, unit/other testing, and general code quality. This process also provides an opportunity to spot check the code for any potential bugs, logic issues or other problems. It is common for this approval gate to require at least two other engineer’s approval before the code changes are allowed to move forward. But all parts of this process vary significantly team by team.

该流程的目的是确保进入项目的代码满足团队中每个人都执行的各种期望和标准。 强制执行的要求通常包括编码样式标准，单元/其他测试以及常规代码质量。 此过程还提供了机会来检查代码是否存在任何潜在的错误，逻辑问题或其他问题。 通常，在允许更改代码进行之前，此批准门通常需要至少两个其他工程师的批准。 但是此过程的各个部分在团队之间差异很大。

Code Reviews should not be the place where feature/implementation design feedback is discussed. This should happen long before code starts to be written.

代码评审不应成为讨论功能/实现设计反馈的地方。 这应该早在开始编写代码之前发生。

他们还提供什么其他好处？ (What Other Benefits Do They Offer?)

As outlined above, Code Reviews provide a number of quality gate, process, and standardization benefits. But there are many more, often less appreciated, potential benefits to the team, the resulting code, and the project as a whole. These are just my top three.

如上所述，代码审查提供了许多质量控制，过程和标准化方面的好处。 但是，对于团队，所产生的代码以及整个项目而言，还有很多(通常是很少被人们所理解的)潜在利益。 这些只是我的前三名。

分享项目知识 (Sharing project knowledge)

Code Reviews are a great way to broadcast detailed knowledge about what changes are happening on a project. Having knowledge shared through the team versus locked up in silos (worst case in silos of one), has a very tangible impact on a project’s momentum and future. For those on the team actively participating in the Code Reviews, it acts as a ‘news beat’ or a pulse of the changes flowing into the codebase. This enables engineers to both stay up to date on how things work, but also allows them to plan their current and future work by taking these changes into account. For example, seeing an area of code is changing can help avoid conflicts if another engineer is about to make changes in the same area. Additionally, it may influence the implementation details of their next task if there is overlap.

代码审查是一种传播有关项目中正在发生的更改的详细知识的好方法。 通过团队共享知识，而不是陷入孤岛( 最坏的情况是一个孤岛 )，对项目的发展势头和未来产生了非常明显的影响。 对于那些积极参与代码审查的团队而言，它就像是“新闻快讯”或流向代码库的变更脉动。 这使工程师不仅可以随时了解工作原理，还可以通过考虑这些变化来计划当前和将来的工作。 例如，如果另一个工程师要在同一区域进行更改，那么查看代码区域是否正在更改可以帮助避免冲突。 此外，如果有重叠，可能会影响其下一个任务的实现细节。

On top of all of this, if your project involves an element of on-call rotation for handling live site issues/incidents, then Code Reviews provide a heads up for changes about to be deployed to Production. The on-call engineer can use the feed of incoming code changes to raise their awareness of what is changing. This helps speed up the identification of the source of issues if things start to fail in Production. When incidents occur, it is often due to changes somewhere in the pipeline.

最重要的是，如果您的项目涉及用于处理现场现场问题/突发事件的呼叫轮换元素，则代码审查会提供有关即将部署到生产中的更改的提示。 待命工程师可以使用传入代码更改的提要来提高他们对更改内容的意识。 如果生产中开始出现故障，这有助于加快问题来源的识别。 发生事件时，通常是由于管道中某处的更改。

教书的机会 (Opportunities to teach)

Having a gate blocking unreviewed code changes going in helps ensure the health and quality of the codebase. But keeping the quality of code high requires continuous learning and education across the whole team. Code Reviews provide a direct and explicit way for the senior members of the team to teach those that are more junior. The very intent of a Code Review is to seek feedback and make the necessary changes before the code is considered ready. This explicitness removes some of the awkward barriers around providing feedback. In the context of a Code Review, the feedback is not unwarranted or unprovoked criticism. It is sought after and discussed in a public venue. This transparency helps ensure that the feedback provided is constructive and allows the feedback itself to be reviewed and critiqued.

有一个门来阻止未审查的代码更改，有助于确保代码库的健康和质量。 但是要保持较高的代码质量，需要整个团队不断学习和教育。 代码审查为团队的高级成员提供了直接和明确的方式来教那些初级的成员。 代码审查的目的是在代码准备就绪之前寻求反馈并进行必要的更改。 这种明确性消除了提供反馈方面的一些尴尬障碍。 在《规范审查》的背景下，反馈并非无端或无端的批评。 在公共场所受到追捧和讨论。 这种透明性有助于确保所提供的反馈具有建设性，并允许对反馈本身进行审查和评论。

Encouraging this culture of asking for, providing, and accepting feedback as part of the standard process helps the team move forward in a unified way. Many senior engineers will eagerly take the opportunity to help drive the team’s standards, mentor those more junior to the codebase, and lead by example. And this is a great growth opportunity for them.

鼓励在标准流程中寻求，提供和接受反馈的这种文化有助于团队以统一的方式前进。 许多高级工程师将热切地抓住机会，帮助推动团队的标准，指导那些对代码库更初级的人，并以身作则。 对于他们来说，这是一个巨大的增长机会。

学习机会 (Opportunities to learn)

Receiving constructive feedback directly on the code you are developing is a great way to keep you focused on code quality. But Code Reviews offer other, more fruitful, ways to learn too.

直接接收有关正在开发的代码的建设性反馈是使您专注于代码质量的好方法。 但是Code Review还提供了其他更有效的学习方法。

Code Reviews are a great opportunity for those new to a codebase to see how the more seasoned on the team work. By taking the time to peruse current and existing Code Reviews, an engineer can get insight into how the team operates and how specific engineers approach problems. It is a good way to get exposure to different coding styles, problem solving and design patterns, and the inner workings of a system. As well as to observe the etiquette of the team, both in how they give and receive feedback, as well as adherence to coding standards and other expectations. Ideally, the Code Reviews should also provide specific context on the code being observed and discussion/feedback around the choices made, versus trying to wade through an enormous codebase without a guide.

对于那些刚接触代码库的人来说，代码审查是一个很好的机会，以了解团队中经验更丰富的人员如何工作。 通过花时间仔细阅读当前和现有的代码审查，工程师可以洞悉团队的运作方式以及特定工程师如何解决问题。 这是接触不同编码风格，问题解决和设计模式以及系统内部工作的好方法。 除了观察团队的礼节外，他们如何提供和接收反馈，以及遵守编码标准和其他期望。 理想情况下，代码审查还应该提供有关正在观察的代码的特定上下文以及围绕所做选择的讨论/反馈，而不是尝试在没有指南的情况下浏览庞大的代码库。

Given all these reasons I strongly encourage every engineer on my team to carve out time to participate in Code Reviews. Whether they are seniors helping raise the standards and educate others, juniors looking to expand their experience and exposure to other’s code, or anyone wanting to keep relevant on the changes flowing into a project. There is a lot of information to be gained by being a part of those discussions.

出于所有这些原因，我强烈鼓励团队中的每位工程师花时间参加代码审查。 无论他们是帮助提高标准和教育他人的高年级学生，还是希望扩大他们的经验并接触他人法规的大三学生，还是任何想与项目变更保持联系的人。 作为这些讨论的一部分，可以获得很多信息。