代码审查的重要性

I recently read this on Twitter:

我最近在Twitter上阅读了此内容：

Sadly, it seems code reviewing is a practice that’s foreign to many students, freelancers and agencies. [Translated]

可悲的是，代码审查似乎对许多学生，自由职业者和代理机构来说都是陌生的。 [翻译]

Apparently, it’s not obvious to everyone that code reviews are actually helpful. Call me naive, but I really thought it was a process used in all IT companies. Apparently I was wrong, and it scares me.

显然，对于所有人来说，代码审查实际上是有帮助的并不明显。 叫我天真，但我真的认为这是所有IT公司都使用的过程。 显然我错了，这使我感到恐惧。

In this article, I’d like to give my thoughts on code reviews, why I believe they’re an important part of the code shipping process, and how to get started with them. If you don’t do code reviews, or if you feel like you could do better, I hope this write-up will help!

在本文中，我想对代码审查提出自己的想法，为什么我认为它们是代码交付过程的重要组成部分，以及如何开始使用它们。 如果您不进行代码审查，或者您觉得自己可以做得更好，那么希望本文对您有所帮助！

什么是代码审查？ (What Is a Code Review?)

We live in the era of Wikipedia, so allow me to begin by quoting the definition given on the Code review entry:

我们生活在Wikipedia时代，因此，让我首先引用“ 代码审查”条目上给出的定义：

Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.

代码检查是计算机源代码的系统检查(有时称为同级检查)。 它旨在发现在初始开发阶段被忽略的错误，从而提高软件的整体质量。 审核以各种形式进行，例如配对编程，非正式演练和正式检查。

A code review, as the name states, is the process of reviewing some code in order to make sure it works, and in order to improve it where possible.

顾名思义，代码审查是审查某些代码以确保其有效并在可能的情况下对其进行改进的过程。

进行代码审查的方法 (Ways to Do a Code Review)

As the Wikipedia definition notes, there are various ways to perform code reviews. However, in a world where so much code lives on GitHub, code reviewing often goes hand-in-hand with what we call a “pull request”.

正如Wikipedia定义所指出的，有多种方法可以执行代码审查。 但是，在世界上有大量代码存储在GitHub上的世界中，代码审查通常与我们所谓的“拉取请求”并驾齐驱。

A pull request is a request to introduce changes to a code repository using a distributed version control system (Git, SVN, Mercurial etc.). It works by “pulling” the original code, applying changes, then submitting a request to merge the changes in.

拉取请求是使用分布式版本控制系统(Git，SVN，Mercurial等)将更改引入代码存储库的请求。 它的工作原理是“拉”原始代码，应用更改，然后提交合并更改的请求。

GitHub made this process particularly easy and efficient thanks to its friendly user interface, abstracting most of the Git knowledge requirements.

GitHub的友好用户界面抽象了大多数Git知识要求，从而使该过程特别容易和高效。

为什么要审查代码问题 (Why Reviewing Code Matters)

So, why does code reviewing matter? After all, we’re all competent here. Surely we can ship code without having someone metaphorically standing over our shoulder, watching everything we do.

那么，为什么代码审查很重要？ 毕竟，我们在这里都有能力。 当然，我们可以发布代码，而无需隐喻地站在我们的肩膀上，看着我们所做的一切。

In theory, yes. But in practice, there are many reasons why having an established code reviewing process helps. Let’s look at a few of them.

从理论上讲，是的。 但是实际上，有许多原因可以帮助建立已建立的代码审查过程。 让我们看看其中的一些。

它限制了风险 (It limits risks)

This is probably the most important reason of all. Having someone double-checking our work never hurts, and limits the risk of unnoticed mistakes. Even good developers get tunnel vision sometimes.

这可能是最重要的原因。 让某人仔细检查我们的工作不会造成任何伤害，并减少了未被注意的错误的风险。 即使是优秀的开发人员，有时也会获得隧道视野。

It’s always good to make sure not to forget anything. For instance, proper keyboard navigation, screen reader accessibility, flexibility for internationalization and friendly, non-JavaScript behavior are often forgotten topics in the front-end world, to name but four.

确保不要忘记任何东西总是很好的。 例如，正确的键盘导航，屏幕阅读器的可访问性，国际化的灵活性以及友好的非JavaScript行为通常是前端世界中被遗忘的主题，仅举四个。

它极大地提高了代码质量 (It dramatically improves code quality)

Let’s make something clear: this is not about standards and code linting (at least not exclusively). It’s about making code more efficient.

让我们弄清楚一点：这不是关于标准和代码替换(至少不是排他性的)。 这是关于使代码更高效。

In a team where everybody has their own background and strong suits, asking for improvements (because that’s what it’s about) is always a good idea. Someone could suggest a smarter solution, a more appropriate design pattern, a way to reduce complexity or to improve performance.

在每个人都有自己的背景和强壮西装的团队中，寻求改进(因为这就是要解决的问题)始终是一个好主意。 有人可能会提出更聪明的解决方案，更合适的设计模式，降低复杂性或提高性能的方法。

它使每个人都更好 (It makes everyone better)

By joining forces, everyone can learn and get better. The code submitter is likely to receive feedback on their work, making them aware of possible problems and areas for improvement. The reviewers could well learn new things by reading through the code, and figure out solutions applicable to their own work.

通过共同努力，每个人都可以学习并不断进步。 代码提交者可能会收到有关其工作的反馈，使他们意识到可能存在的问题和需要改进的地方。 审阅者可以通读代码来很好地学习新事物，并找出适用于自己工作的解决方案。

它有助于熟悉项目 (It helps being familiar with the project)

When a team works on a project, it’s highly unlikely that every developer is working on every part of the application. Sometimes a developer will heavily work on one large part for a while, while another one is working on something else entirely.

当团队从事项目时，每个开发人员都不可能在应用程序的每个部分上工作。 有时，开发人员会在一段时间内大量工作，而另一开发人员则完全在进行其他工作。

Doing code reviews helps people familiarize themselves with code they haven’t written but might be asked to maintain in the future. It promotes knowledge of the codebase across the team, and is likely to speed up future development.

进行代码审查有助于人们熟悉他们尚未编写但将来可能需要维护的代码。 它促进了整个团队对代码库的了解，并有可能加速未来的开发。

如何正确做 (How To Do It Properly)

Again, having an established code reviewing process is both extremely useful and important. Every team producing code should have some code review, one way or the other.

同样，建立已建立的代码审查过程非常有用且重要。 每个编写代码的团队都应该以某种方式对代码进行某种审查。

That being said, doing meaningful and helpful code reviews is not always as straightforward as it might seem. Worry not, it’s not like it’s going to bite you if it’s done poorly. It simply won’t be useful, and could feel like a waste of time.

话虽如此，进行有意义且有用的代码审查并不总是看起来那么简单。 不用担心，如果做得不好，它不会咬你。 它根本不会有用，可能会浪费时间。

Recently at my workplace, we had a retrospective about our code reviewing process. We knew some things were wrong when we realized only 3 out of 12 developers were engaging in code reviews.

最近在我的工作场所，我们回顾了代码审查过程。 当我们意识到12个开发人员中只有3个正在进行代码审查时，我们知道有些错误。

To help us change this, one of our Scrum Masters organized a retrospective to determine where there was room for improvement, and how we could bring it about.

为了帮助我们改变这一点，我们的一名Scrum大师组织了一次回顾展，以确定在哪里还有改进的余地，以及我们如何实现这一改进。

提前计划 (Planning ahead)

The most recurrent argument to justify the lack of participation in code reviews was that it takes time — time that people can’t or aren’t willing to take.

证明缺乏参与代码审查的理由的最经常性的论点是，这需要时间-人们不能或不愿意花费时间。

I must say I don’t really understand this argument myself, because I picture it like this: if a colleague comes to me directly and asks me to help them with something, I’m not going to say — “Don’t have time, not interested.” I’m going to find time to help. Maybe not right now, maybe in an hour — but I will obviously take time for them. Why? Because

我必须说我自己并不真正理解这种说法，因为我的想法是这样的：如果一个同事直接找我并要我帮助他们做点什么，我不会说-“没有时间， 没兴趣。” 我会找时间帮助。 也许不是现在，也许一个小时之内-但我显然会花些时间为他们服务。 为什么？ 因为

• this is what being part of a team means
  这就是团队成员的意义
• if they want my opinion, it’s because they value it one way or another, and therefore it makes only sense to give them.
  如果他们想要我的意见，那是因为他们以一种或另一种方式重视它，因此给予他们意见才有意义。

“Why don’t you take part in the code reviewing process?”

“为什么不参加代码审查过程？”

“I don’t have time.”

“我没有时间。”

To me, a pull request is no different from a coworker asking for help. Saying you don’t have time is perfectly fine from time to time, but by systematically refusing to help, you’re actively pulling yourself out of the team. This behavior is neither friendly nor positive. Take the time to help.

对我来说，请求请求与同事寻求帮助没有什么不同。 有时会说您没有时间是完全可以的，但是通过系统地拒绝提供帮助，您正在积极地使自己退出团队。 这种行为既不友好也不积极。 花时间帮助。

To make it possible for developers to find time, we started taking into account that every developer will spend a bit of time (maybe 30 minutes) reviewing code every day. No more surprise when we end up spending half an hour on a large code review: it’s part of the day.

为了使开发人员能够找到时间，我们开始考虑到每个开发人员每天都会花费一些时间(可能是30分钟)来检查代码。 当我们最终花了半个小时进行大型代码审查时，这并不奇怪：这是一天的一部分。

We also tried to dramatically reduce the amount of code constituting a pull request. We used to have mammoth pull requests — of thousands of changes across dozens of files.

我们还试图大大减少构成拉取请求的代码量。 我们曾经有过巨大的请求请求-在数十个文件中进行数千次更改。

We try not to do that anymore. By making smaller pull requests, we make them easier to review, the feedback more relevant, and developers more willing to engage in this process. “Ship small and often.”

我们尝试不再这样做。 通过提出较小的拉取请求，我们使它们更易于审核，反馈更相关，并且开发人员更愿意参与此过程。 “经常运送船只。”

提供背景 (Giving context)

The second biggest problem we found was that we usually lacked an understanding of the code’s context, which is needed if you’re going to provide helpful feedback. When missing the context, we usually did no more than a syntax review — which, though useful to some extent, is not enough. You simple become what we call a “human linter”.

我们发现的第二个最大问题是，我们通常对代码的上下文缺乏了解，如果您要提供有用的反馈，则需要这样做。 当缺少上下文时，我们通常只进行语法检查-尽管在某种程度上有用，但还不够。 您简单地成为我们所谓的“人类短毛猫”。

Fortunately, the solution to this problem is relatively simple: add a description to the pull request to explain what the objective is, and how to get there. It doesn’t have to be a wall of text; just a few lines are usually enough. It also helps to add a link to the issue and/or story. Liv Madsen, one of our developers, even adds screenshots — or screencasts when relevant — to illustrate what she’s done, which is amazing.

幸运的是，该问题的解决方案相对简单：在请求请求中添加描述以说明目标是什么以及如何实现。 它不必是一堵墙。 通常只有几行就足够了。 它还有助于添加指向问题和/或故事的链接。 我们的开发人员之一Liv Madsen甚至添加了屏幕截图(或相关时的屏幕录像)来说明她的工作，这真是太神奇了。

其实问 (Actually asking)

The third problem we pointed out was that we sometimes simply didn’t realize there was something to review. Let’s face it, we’re flooded with tons of emails and notifications every day — so much so that it can be hard to keep track. We’re only human, after all.

我们指出的第三个问题是，有时我们根本没有意识到需要复审。 面对现实，每天我们到处都是无数的电子邮件和通知-数量如此之多，以至于很难追踪。 毕竟，我们只是人类。

Here, again, the solution is pretty simple: actually ask someone for a review. There are many ways to do that, from honking a horn in the office to pinging someone on Slack; to each team their own.

同样，这里的解决方案非常简单：实际上是要求某人进行审查。 有很多方法可以做到这一点，从在办公室鸣喇叭到在Slack上敲击某人； 给每个团队自己的。

We created groups on GitHub based on our activity, and when submitting a pull request, we always ping a group. Members of this group will receive a notification and are free to tackle it as soon as they have time. Sometimes, we ping a developer (or several) directly when it’s more specific to someone’s work. That also works.

我们根据活动在GitHub上创建了群组，并且在提交请求请求时，我们总是对群组进行ping操作。 该小组的成员将收到通知，有时间后便可以自由处理。 有时，当某个开发人员更特定于某人的工作时，我们会直接对其进行ping操作。 那也行。

From there, pinged people can review the code and leave comments. We try to leave a comment even when there’s nothing specific to report — if only to indicate that the code is ready to be merged.

从那里，受查验的人可以查看代码并发表评论。 即使没有什么要报告的内容，我们也尝试发表评论，即使只是表明已准备好合并代码。

Because we had some pull requests blindly merged regardless of given comments, we established a strict “reply or fix everything” policy. When receiving feedback, either you fix it or you reply to explain why you didn’t. In any case, you never leave a comment pending, and you certainly don’t merge your pull request with non-handled comments.

因为不管给出的注释如何，我们都会盲目地合并一些拉取请求，所以我们建立了严格的“答复或修复所有问题”策略。 收到反馈后，您可以修复它或答复以解释为什么没有。 无论如何，您永远不会留下评论待处理，当然也不会将拉取请求与未处理的评论合并。

包装东西 (Wrapping Things Up)

Having a regular and efficient code reviewing process is essential to maintain high-quality code standards, grow as a team and share knowledge between developers.

定期进行有效的代码审查过程对于保持高质量的代码标准，团队成长以及在开发人员之间共享知识至关重要。

Asking for a code review is not a mark of weakness. There’s nothing embarrassing about asking for help, and certainly not in the form of a code review. Accept all feedback given to you, and offer constructive (ideally positive) comments to people submitting pull requests.

要求进行代码审查不是弱点。 寻求帮助没有任何尴尬，当然也不是以代码审查的形式。 接受提供给您的所有反馈，并向提交拉取请求的人员提供建设性(理想的正面)评论。

Find what works for you. Reviewing code should be a large part of the code shipping process, so you should tailor it to your team. Make it the way you want so that it’s helpful and positive for everybody.

找到适合您的东西。 审核代码应该是代码交付过程的很大一部分，因此您应该根据团队进行调整。 随心所欲，对每个人都有帮助和积极作用。

Happy reviewing!

审核愉快！

翻译自: https://www.sitepoint.com/the-importance-of-code-reviews/