验证码最佳实践_经过验证的代码审查最佳实践

验证码最佳实践

What are the code review best practices companies such as Microsoft follow to ensure great code review feedback? How do you stay productive while doing code reviews? Learn proven code review best practices from Microsoft in this article.

微软(Microsoft)遵循哪些代码审查最佳实践来确保获得出色的代码审查反馈？在进行代码审查时，如何保持生产力？本文中提供了从Microsoft了解经过验证的代码审查最佳实践。

The benefits of code reviews rise and fall with the value of the code review feedback. If done correctly, code reviews can help to ensure a high-quality code base. However, if teams are not aware of and do not follow code review best practices, developers may experience several code review pitfalls. In the worst case, reviewing code can slow your team down.

代码审查的好处随着代码审查反馈的价值而上升和下降。如果做得正确，代码审查可以帮助确保高质量的代码库。但是，如果团队不了解并且不遵循代码审查最佳实践，则开发人员可能会遇到一些代码审查陷阱。在最坏的情况下，检查代码可能会使您的团队慢下来。

I have been researching and working with teams at Microsoft for several years. Through several large scale-studies, we discovered a number of code review best practices that help teams stay productive and boost their code review value. But first, let’s start at the beginning. What does code review look like?

我一直在Microsoft的团队进行研究和合作。通过几次大规模研究，我们发现了许多代码审查最佳实践，这些最佳实践可帮助团队保持生产力并提高其代码审查价值。但是首先，让我们从头开始。代码审查是什么样的？

典型的代码审查过程 (A typical code review process)

A typical tool-based code review process starts when the engineer prepares the code for review. Then, she selects relevant reviewers for the code change. The reviewers are notified and give feedback on the code. The code review author works on the feedback until all parties are satisfied. Then, the code is checked into the common code base.

当工程师准备要检查的代码时，就会开始一个典型的基于工具的代码检查过程。然后，她为代码更改选择相关的审阅者。审阅者将收到通知并提供有关代码的反馈。代码审查作者将对反馈进行处理，直到各方满意为止。然后，将代码检入公共代码库。

A typical tool-based code review

典型的基于工具的代码审查

To ensure that this process is smooth and does not become a nightmare, it is important to understand code review pitfalls and which code review best practices you can follow to overcome those.

为确保此过程顺利进行且不会成为噩梦，了解代码审查陷阱以及可以遵循哪些代码审查最佳实践来克服这些缺陷非常重要。

The main code review pitfalls are:

主要的代码审查陷阱如下：

not getting useful feedback,
没有得到有用的反馈，
not having enough time to do code reviews,
没有足够的时间进行代码审查，
code reviews taking too long causing long waiting times.
代码审查花费的时间太长，导致等待时间长。

The code review best practices I present below help counteract those pitfalls, by making the job of the reviewers as easy as possible. They also help the reviewer to focus on providing valuable feedback.

我在下面介绍的代码审查最佳实践通过使审查者的工作尽可能轻松来帮助弥补这些陷阱。它们还帮助审阅者专注于提供有价值的反馈。

针对代码作者的代码审查最佳实践 (Code review best practices for code authors)

In a code review, there are two different stakeholders: the code author who asks for feedback and the code reviewers, who look through the code change and provide the feedback. As a code review starts with the author, I explain the code review best practices for code authors first.

在代码审查中，有两个不同的涉众：请求反馈的代码作者和审查代码更改并提供反馈的代码审查者。当代码审查从作者开始时，我首先向代码作者解释了代码审查的最佳实践。

For my e-mail subscribers, I prepared an exclusive code review e-book including a checklist with all code review best practices. I also added additional bonus insights. You can request the Code Review e-Book here.

对于我的电子邮件订阅者，我编写了一份独家的代码审查电子书，其中包括具有所有代码审查最佳实践的清单。我还添加了其他奖励见解。您可以在此处索取《代码审查》电子书。

仔细阅读更改 (Read through the change carefully)

The first code review best practice is to read carefully through the code change before submitting the code for review. There is nothing worse than asking several developers to look through the code and give feedback on issues you could have fixed yourself.

第一个代码审查最佳实践是在提交代码进行审查之前，仔细阅读代码更改。没有什么比让几个开发人员仔细检查代码并就您可能已解决的问题提供反馈更糟糕的了。

This wastes everyone’s time and it might make you look bad. For future code reviews, developers may also be reluctant to review your code.

这浪费了每个人的时间，并可能使您看起来不好。对于将来的代码审查，开发人员可能也不愿意审查您的代码。

So, ensure you use a code review tool or a diff tool that can highlight what changed between this and the previous version. Because the code is presented in a different way and changed code passages are highlighted, it makes it easier for you to review your code yourself before sending it out.

因此，请确保您使用的代码查看工具或差异工具可以突出显示此版本与先前版本之间的更改。因为代码以不同的方式显示，并且突出显示了更改的代码段落，所以它使您可以更轻松地在发送代码之前自己检查代码。

Often you will see changes that you actually forgot you made or missing issues highlighted you should fix before asking somebody to review.

通常，您会看到实际上忘记所做的更改，或者遗漏了一些突出的问题，因此您应该先进行修复，然后再要求其他人进行审核。

The best time to fix issues is before the code is sent out for review. (Click to tweet).

解决问题的最佳时间是在将代码发送出去进行审核之前。 (点击鸣叫)。

Thoroughly look through your code before submitting for review (Photo by Marten Newhall on Unsplash)

在提交审核之前，请仔细检查代码( Marten Newhall在Unsplash上摄 )

瞄准微小的增量变化 (Aim for small, incremental changes)

As a developer, you should always strive for small, incremental and coherent changes. This best practice helps when working with code revision tools, such as git or SVN.

作为开发人员，您应该始终努力进行细微，增量和一致的更改。在使用代码修订工具(例如git或SVN)时，此最佳做法会有所帮助。

Small, incremental code changes are also a crucial code review best practice as other developers must be able to understand your code change in a small amount of time.

较小的增量代码更改也是关键的代码审查最佳实践，因为其他开发人员必须能够在短时间内理解您的代码更改。

10 lines of code = 10 issues.

10行代码= 10个问题。

500 lines of code = “looks fine.”

500行代码=“看起来不错”。

Code reviews.

代码审查。

- I Am Devloper (@iamdevloper) November 5, 2013

-我是Devloper(@iamdevloper) ，2013年11月5日

If several changes with different purpose happen within one code review the task of code reviewing becomes more difficult. This also decreases the ability of code reviewers to spot problems with the code. In several studies, we see that the value of the code review feedback decreases with the size of the change under review.

如果在一个代码审查中发生了不同目的的几项变更，则代码审查的任务将变得更加困难。这也降低了代码审阅者发现代码问题的能力。在一些研究中，我们看到代码审查反馈的价值随着审查中变更的大小而减小。

On the other hand, you also want to make sure the changes are coherent. Rarely code changes are too small to be sent out. It happens, but, not that often.

另一方面，您还想确保更改是一致的。很少有代码更改太小而无法发送出去。它发生了，但是并不经常发生。

The quality and value of code review feedback decrease with the size of the change. (Click to tweet).

代码审查反馈的质量和价值随更改的大小而降低。 (点击鸣叫)。

Another code review best practice is to cluster related code changed. Imagine you plan to add some new functionality, fix a bug in another function, and refactor a class. Then, each of those changes should be a separate code review. This way, you ensure the purpose of the code change is clear to the reviewers. A clear purpose makes the reviewing job much easier and increases the feedback value.

另一个代码审查最佳实践是将集群相关代码更改。假设您计划添加一些新功能，修复另一个功能中的错误，然后重构一个类。然后，每个更改都应进行单独的代码审查。这样，您可以确保代码更改的目的对审阅者是清楚的。明确的目的使审核工作变得更加容易，并增加了反馈价值。

描述变革的目的和动机 (Describe the purpose and motivation of the change)

One way to make sure you invest your time right during code review preparation is to write a description of what this code change is all about. With a small note, you help the code reviewers to understand the purpose of the code change and also why you changed it. This code review best practice speeds up code review time, increases the quality and value of the feedback, and improves code review participation rates.

确保在代码检查准备期间正确投入时间的一种方法是编写有关此代码更改的全部内容的描述。只需一点点，便可以帮助代码审阅者了解代码更改的目的以及更改原因。此代码审查最佳实践可加快代码审查时间，提高反馈的质量和价值，并提高代码审查参与率。

Code reviewing isn’t a puzzle. Help reviewers focus on key issues by describing the code change. (Photo by Hans-Peter Gauster on Unsplash)

代码审查不是难题。 通过描述代码更改，帮助审阅者将重点放在关键问题上。 (照片由Hans-Peter Gauster在Unsplash上拍摄 )

Code reviewing isn’t a puzzle. Help reviewers focus on key issues by describing the code change. (Click to tweet).

代码审查不是难题。通过描述代码更改，帮助审阅者将重点放在关键问题上。 (点击鸣叫)。

Interestingly, in our studies, we observed that developers really appreciate code change description. They actually wish that more people would write descriptions. On the other hand, we saw that the same developers did not always include descriptions themselves.

有趣的是，在我们的研究中，我们发现开发人员真的很喜欢代码更改描述。他们实际上希望更多的人会写描述。另一方面，我们看到相同的开发人员并不总是自己包括描述。

One reason for this is that when you write the code yourself, you are so involved with the code that you think it is self-explanatory. Fact is, it is not.

造成这种情况的原因之一是，当您自己编写代码时，您对代码的参与如此之深，以至于它是不言自明的。事实是，不是。

And if you do not help the reviewers to understand the code, they will not be able to provide valuable feedback.

并且，如果您不帮助审核者理解代码，他们将无法提供有价值的反馈。

So, write the note, even if it just says: “Updated the API endpoint to be compliant with security regulations”.

因此，即使该注释只是说：“已更新API端点以符合安全法规”，也要写注释。

How much easier did the job of reviewing the code just get with this note? Remember, code reviewing isn’t a puzzle!

仅凭此注释，审查代码的工作变得容易了多少？记住，代码审查不是难题！

Even if the code change seems trivial to you, add a description, so reviewers know what to expect (Click to tweet).

即使代码更改对您而言似乎微不足道，也请添加描述，以便审阅者知道会发生什么(单击鸣叫)。

在提交代码审查之前运行测试 (Run tests before submitting a code review)

Yes, take the time to run the tests for your code change. Testing isn’t only a best engineering practice, but it’s also a code review best practice. Because testing your code ensures that the code actually works before you ask for feedback.

是的，请花一些时间运行测试以更改代码。测试不仅是最佳的工程实践，而且还是代码审查的最佳实践。因为测试您的代码可以确保代码在您征求反馈之前确实可以正常工作。

In addition, it shows that you respect the time of the code reviewers. It is not only embarrassing to send out code that obviously (as the tests show) is not working as expected, it also kills everyone’s productivity. So, run the tests first!

此外，它表明您尊重代码审阅者的时间。发出令人费解的代码(如测试所示)显然不能按预期工作，这不仅令人尴尬，而且还会浪费每个人的工作效率。因此，请先运行测试！

自动化什么可以自动化 (Automate what can be automated)

As one of the main pitfalls for code reviews is taking too long, you better follow the code review practices of automating what can be automated.

由于代码审查的主要陷阱之一是花费的时间太长，因此您最好遵循使可自动化的代码自动化的代码审查实践。

Use style checkers, syntax checkers and other automated tools like static analysis tools to help improve the code. This way, you make sure that code reviewers can really concentrate on giving valuable feedback and do not need to use their time to comment on issues that can be found automatically.

使用样式检查器，语法检查器和其他自动化工具(例如静态分析工具)来帮助改进代码。这样，您可以确保代码审阅者可以真正专注于提供有价值的反馈，而无需花费时间评论可以自动发现的问题。

跳过不必要的评论 (Skip unnecessary reviews)

You read that right. Some reviews can be skipped. Obviously, it depends on your organizational policies, but if they permit it, you might consider skipping code reviews.

您没看错。可以跳过某些评论。显然，这取决于您的组织策略，但是如果他们允许，则可以考虑跳过代码审查。

But stop before heading out and telling your team you need no code reviews anymore. Skipping code reviews is only advisable for trivial changes that do not change the logic such as commenting, formatting issues, renaming of local variable or stylistic fixes.

但是请停下来，然后告诉您的团队您不再需要任何代码审查。建议仅对那些不会改变逻辑的琐碎更改(例如注释，格式问题，重命名局部变量或样式修复)跳过代码检查。

Skipping unnecessary code reviews boosts your productivity. Click to tweet.

跳过不必要的代码审查可提高您的生产率。点击鸣叫。

不要选择太多评论者 (Do not select too many reviewers)

You should select the right number of reviewers for your code change. If now numbers above 4 people come to your mind, I’d like you to stop right there. Because adding too many developers on code reviews does more harm than good.

您应该为代码更改选择适当数量的审阅者。如果现在想到4位以上的人，我希望您就此停下来。因为在代码审查中添加过多的开发人员弊大于利。

One problem is that if you add too many developers, each one of them feels less responsible to give feedback. Another issue is that adding more people than necessary decreases your team’s productivity.

一个问题是，如果您添加了过多的开发人员，那么每个开发人员都会觉得反馈的责任减少了。另一个问题是，增加不必要的人员会降低团队的生产力。

Some studies suggest the code review best practice of adding only two active reviewers.

一些研究提出了仅添加两个活动审阅者的代码审阅最佳实践。

For some code changes, you want additional experts like security experts or developers from other teams to look through the code. But, more often than not, two active reviewers are just fine.

对于某些代码更改，您希望安全专家或其他团队的开发人员等其他专家来检查代码。但是，经常有两个积极的审稿人就可以了。

Many code review tools allow notifying developers without making them mandatory reviewers. This ensures that they stay in the loop and are aware of what is happening, but removes the obligation for them to comment on your code.

许多代码检查工具允许通知开发人员而无需使他们成为强制检查者。这样可以确保他们留在循环中并知道发生了什么，但免除了他们注释您的代码的义务。

添加经验丰富的审稿人以获得有见地的反馈 (Add experienced reviewers to get insightful feedback)

Studies have shown that the most insightful feedback comes from reviewers that have worked on the code you are going to change before. They are the ones that give the most insightful feedback.

研究表明，最有见地的反馈来自审阅者，这些审阅者曾经处理过要更改的代码。他们是提供最有见地反馈的人。

How often a reviewer has already reviewed code influences the ability to give useful feedback. Similar, experienced and senior developers tend to give better code review feedback.

审阅者已经审阅代码的频率会影响提供有用反馈的能力。类似的，经验丰富的高级开发人员往往会提供更好的代码审查反馈。

But, be mindful about the workload of senior engineers, as they tend to be added as reviewers a lot.

但是，请注意高级工程师的工作量，因为他们往往会被添加为审阅者。

Developers that changed or reviewed pieces of the code before, give the most valuable code review feedback. (Click to tweet).

之前更改或检查过代码段的开发人员会提供最有价值的代码检查反馈。 (点击鸣叫)。

添加初级开发人员以使他们学习 (Add junior developers to let them learn)

One of the code review goals is training and learning, so do not forget to include junior developers. Consider adding reviewers that are not familiar with the code base, but that would benefit from the knowledge to allow knowledge dissemination.

代码审查的目标之一是培训和学习，因此不要忘记包括初级开发人员。考虑添加不熟悉代码库但可以从知识中受益以允许知识传播的审阅者。

通知受益于此评论的人 (Notify people that benefit from this review)

For some people, like project managers or team leads, receiving notification about code reviews (without being actually required to do the code review) is beneficial. But, you have to take a conscious decision on whom you gonna notify. Not everybody really cares or should care about your code review.

对于某些人，例如项目经理或团队负责人，接收有关代码审查的通知(实际上并不需要执行代码审查)是有益的。但是，您必须明智地决定要通知谁。不是每个人都真正关心或应该关心您的代码审查。

不要通知太多人 (Don’t notify too many people)

Do not add everybody on the notification list. Only add people who actually benefit from the information that a code review is in the process.

不要在通知列表中添加所有人。仅添加真正从代码审查过程中的信息中受益的人员。

I have seen teams, where each team member was added to each of the code review of the extended team by default (+70 people). This practice is like adding nobody to the list. Or in the worst case, you have several of your engineers spending their time looking through hundreds of code reviews to figure out if it’s relevant for them.

我见过团队，默认情况下，每个团队成员都被添加到扩展团队的每个代码审查中(+70人)。这种做法就像将任何人都添加到列表中。或者，在最坏的情况下，您有几个工程师花时间查看数百个代码审查，以找出是否与他们相关。

在审核前给审核者一些提示 (Give reviewers a heads-up before the review)

A really effective code review best practice is to let your co-workers know ahead of time that they will receive a code review soon. This code review best practice reduces turn-around times substantially.

真正有效的代码审查最佳实践是让您的同事提前知道他们将很快收到代码审查。该代码审查最佳实践大大减少了周转时间。

So, let them know a code review is coming their way as soon as possible.

因此，让他们知道代码审查将尽快到来。

Giving people a heads-up that a code review is on its way can speed up review time. (Click to tweet).

让人们意识到代码审查正在进行中可以加快审查时间。 (点击鸣叫)。

对建议的变化持开放态度 (Be open to suggested changes)

Receiving unexpected comments or feedback might make you tense and defensive. Try to prepare yourself mentally and work on your ability to be open to suggestions and different viewpoints. Always start with the assumption that the reviewer had the best intention.

收到意想不到的评论或反馈可能会使您感到紧张和防御。尝试做好心理准备，并努力接受建议和不同观点。始终从假设审阅者具有最佳意图开始。

If some feedback made you uncomfortable try to sort things out as soon as possible. Sometimes it is a good idea to have more personal face-to-face conversations to resolve some issues.

如果有一些反馈让您感到不舒服，请尝试尽快解决问题。有时，进行更多个人面对面的对话以解决某些问题是一个好主意。

Don’t be defensive if confronted with unexpected feedback. (Photo by Sweet Ice Cream Photography on Unsplash)

如果遇到意外的反馈，请不要采取防御措施。 (照片由Sweet Splash 摄影在Unsplash上拍摄 )

对审稿人表示敬意和感谢 (Show respect and gratitude to the reviewers)

Code reviews rise and fall with the team’s feedback culture. As a code author, show gratitude and value the received feedback. Make sure to carefully consider the reviewers’ feedback and communicate throughout the feedback cycle.

代码审查会随着团队的反馈文化而兴衰。作为代码编写者，请感谢并重视收到的反馈。确保仔细考虑审阅者的反馈，并在整个反馈周期内进行沟通。

Tell the reviewers which actions you took and which decisions you made because of the received feedback in a respectful manner.

告诉审阅者，您应该以尊重的态度，根据收到的反馈，采取了哪些行动以及做出了哪些决定。

Code review rises and falls with the quality of the team’s feedback culture. (Click to tweet).

代码审查的兴衰与团队反馈文化的质量有关。 (点击鸣叫)。

But, creating a great feedback culture is a two-way street. Naturally, code reviewers influence the culture a lot. So let us look closely at the code review best practices for code reviewers.

但是，要营造良好的反馈文化是一条两条路。自然，代码审查者会极大地影响文化。因此，让我们仔细查看代码审查人员的代码审查最佳实践。

代码检查人员的代码检查最佳实践 (Code Review Best Practices for Code Reviewers)

Being asked to give feedback on a code review is an honor, so you want to make sure you know how to give valuable code review feedback.

被要求提供对代码审查的反馈是一种荣幸，因此您想确保自己知道如何提供有价值的代码审查反馈。

During code reviews, you can not only demonstrate your skills and knowledge but also mentor other developers and contribute to the team’s success. Nothing worth than investing time in code reviews and not getting valuable feedback.

在代码审查期间，您不仅可以展示自己的技能和知识，还可以指导其他开发人员，为团队的成功做出贡献。没有什么比在代码审查上花费时间并且没有获得有价值的反馈有价值的了。

提供尊重和建设性的反馈 (Give respectful and constructive feedback)

Even though it reads like a no-brainer, code reviews do put the code author in a vulnerable position, so you must be considerate of that. Your job is it to give constructive and valuable feedback but also to do so in a respectful manner.

即使读起来很容易，代码审查的确会使代码作者处于弱势地位，因此您必须考虑到这一点。您的工作是提供建设性和有价值的反馈，同时也要以尊重的态度这样做。

Especially using code review tooling, please reflect on how and what kind of feedback you give. It is just so easy to hurt someone feelings — especially in written form. Too often time pressure might make you give a sloppy answer that can be misinterpreted.

尤其是使用代码审查工具时，请仔细考虑您所提供的反馈方式和反馈类型。伤害某人的感觉非常容易-尤其是以书面形式。太多的时间压力可能会使您给出一个草率的答案，而这个答案可能会被误解。

必要时亲自去聊天 (Go and talk in person if necessary)

Code review tools and chat-tools allow us to communicate with our peers in an asynchronous and effortless way. But, there are quite a few situations where a proper human interaction, either face to face or via voice/video cannot be bet.

代码审查工具和聊天工具使我们能够以异步，轻松的方式与同级通信。但是，在很多情况下，无法下注进行适当的人类互动，无论是面对面还是通过语音/视频。

Complex issues, for example, can be much more efficient and positively resolved once you hop over to your colleague or call her and discuss it personally. The same holds true for contentious issues or sensitive matters.

例如，一旦您跳到您的同事或给她打电话并亲自讨论这个问题，复杂的问题可能会更有效率并得到积极解决。对于有争议的问题或敏感问题也是如此。

Maybe it is a better strategy to write a private email or seek a personal discussion with the code author if you think you might hurt some feelings are make the engineer lose the face. So, whenever you face a complex issue or might hurt some feelings, rethink your communication channels and act accordingly.

如果您认为可能会伤害到某些感觉而使工程师丢脸，那么写一封私人电子邮件或与代码作者进行个人讨论可能是一个更好的策略。因此，每当您遇到复杂的问题或可能会伤及某些感觉时，请重新考虑您的沟通渠道并采取相应的行动。

确保决策的可追溯性 (Ensure traceability for decisions)

Even though less traceable conversations, such as face to face or video calls can make a big difference for team dynamics, it is important to document the discussion. Especially the code review outcome should be tracked for future reference by using traceable tools such as the code review tool.

即使较不易追踪的对话(例如面对面或视频通话)可以对团队动力产生很大的影响，但记录下讨论很重要。特别是应使用诸如代码审查工具之类的可跟踪工具来跟踪代码审查结果，以备将来参考。

The code review tool is the right communication channel for all simple matters, as it allows the whole team to follow along, and enables to look-up decisions and understand code development after the fact.

代码审查工具是解决所有简单问题的正确沟通渠道，因为它使整个团队可以跟进，并能够查找决策并在事后了解代码开发。

Leaving traces about your decisions and changes helps to understand code evolvement (Photo by Marten Bjork on Unsplash)

留下有关您的决策和更改的痕迹有助于理解代码的演变( Marten Bjork在Unsplash上摄 )

总是解释为什么您拒绝更改 (Always explain why you rejected a change)

Let’s be honest. Having a code change rejected isn’t something the code author will enjoy. So, it is important that you are thoughtful and explain your rejection in a polite, constructive and friendly way.

说实话。拒绝代码更改并不是代码作者所喜欢的。因此，重要的是您要有思想，并以礼貌，建设性和友好的方式解释自己的拒绝。

Explaining the reasons behind your decision does not only help the code author to learn and grow but also helps the author to understand your viewpoint. It also promotes an ongoing dialog with the author.

解释您做出决定的原因不仅可以帮助代码作者学习和成长，还可以帮助作者理解您的观点。它还促进了与作者的持续对话。

Tell the code author exactly what she has to do to get the change accepted.

确切地告诉代码作者她需要做什么才能使更改被接受。

If you have to reject a code change, explain exactly what has to happen that the change can be approved. (Click to tweet).

如果您必须拒绝更改代码，请确切说明更改可以被批准的情况。 (点击鸣叫)。

代码审查提高生产力的最佳实践 (Code review best practices for boosting productivity)

Some of the biggest challenges during code reviews, for both the code author and the code reviewer are time constraints.

对于代码作者和代码审阅者而言，代码审阅过程中最大的挑战是时间限制。

As a reviewer, you might find it challenging to take time out of your daily tasks to review the code of your peers. But, code reviews can be very beneficial to you and the team if done in the right way.

作为一名审阅者，您可能会发现抽出日常任务来审阅同行代码的挑战。但是，如果以正确的方式进行代码审查，对您和团队都将非常有益。

将代码审查集成到您的日常工作中 (Integrate code review into your daily routine)

Structure your day-to-day business in a way that you set dedicated time aside just for doing code reviews. For example, plan to work on code reviews every day from 11 to 12 AM.

通过安排专用时间来进行代码审查，来组织日常业务。例如，计划每天上午11点至12点进行代码审查。

This way you make sure you can account the time for code reviews, and also make it an anticipated activity for you and your team. This schedule will come in handy every time you have a reflection on your work progress or an evaluation of your work.

这样，您可以确保可以计算代码审查时间，也可以将其作为您和您的团队的预期活动。每当您对工作进度进行反思或对工作进行评估时，此时间表都会派上用场。

减少任务切换，因为这会降低生产力 (Reduce task switching as it kills productivity)

Switching from one task to another is costly. Knowing you do not stop whatever you do every time a code review comes along your way ensures you can work more focused.

从一项任务切换到另一项任务成本很高。知道每次执行代码审查时都不会停止所做的任何事情，可以确保您可以更加专注。

Which time slots work depends on your workload, the number of code reviews you have to perform as well as on the time those reviews normally come in. In some settings, your team benefits from two (shorter) scheduled reviewing times, such as in the morning and before you leave the office. This way, your peers do not have to wait for your feedback too long.

哪个时间段工作取决于您的工作量，您必须执行的代码审查数量以及这些审查通常进入的时间。在某些设置中，您的团队可以从两个(较短的)预定的审查时间中受益，例如早上和离开办公室之前。这样，您的同伴不必等待您的反馈时间太长。

Task switching kills productivity (Photo by Tim Gouw on Unsplash)

任务切换会降低生产率( Tim Gouw在Unsplash上摄 )

Task switching kills productivity. So have dedicated code review times. #codereview (Click to tweet)

任务切换会降低生产力。因此，有专门的代码审查时间。 #codereview (点击鸣叫)

及时提供反馈 (Give feedback in a timely manner)

It is not advisable to jump right into a code review, whenever the notifications pop up, because of context switching costs. Still, it has several advantages for you and the code author to review the code in a timely matter.

由于上下文切换的成本，每当通知弹出时，建议不要立即进入代码审查。尽管如此，对于您和代码作者而言，及时检查代码仍具有多个优点。

Giving feedback as soon as possible ensures that the code author is not blocked by waiting for feedback. Also, if the author has to wait too long, it becomes harder for her or him to remember the changes and incorporate the feedback. Remember long waiting times are a number one code review pitfall.

尽快给出反馈可确保代码编写者不会因等待反馈而被阻塞。另外，如果作者不得不等待太长时间，那么他或他就很难记住更改并合并反馈。请记住，漫长的等待时间是代码审查的一大陷阱。

Being one of the first reviewers (especially if there are quite a few) also ensures your effort looking through the code actually adds value. If you are the fifth person inspecting the code, chances are you are not going to add new insights anymore. If that happens frequently, you should implement the code review best practice for selecting fewer reviewers.

成为第一批审阅者之一(特别是如果有很多审阅者)还可以确保您通过查看代码的努力实际上可以增加价值。如果您是检查代码的第五个人，那么您将不再有可能添加新的见解。如果这种情况经常发生，则应实施代码审查最佳做法，以选择较少的审查者。

经常回顾而不是大爆炸 (Review frequently not in a big bang fashion)

Research shows that you can give better quality feedback if you review frequently and therefore less changes at a time. That means that you do not wait until several code reviews pile up to look through them in one go. Instead, you stick to your schedule and review one code review (or even parts of one if it is a larger code review) at a time.

研究表明，如果您经常检查并因此一次进行的更改较少，则可以提供更好的质量反馈。这意味着您不必等到几个代码审查堆积起来就可以一次浏览它们。相反，您必须按计划执行，并且一次审阅一个代码审阅(如果是较大的代码审阅，则甚至审阅一部分)。

If code reviews are generally too large and take too long, you can suggest the code review best practices for small, incremental and coherent changes to the code review authors.

如果代码审查通常太大且花费的时间太长，您可以建议代码审查最佳实践，以便对代码审查作者进行小的，增量和一致的更改。

Give better quality feedback to code reviews by not letting them pile up. (Click to tweet).

通过避免代码堆积，为代码审查提供更好的质量反馈。 (点击鸣叫)。

专注于核心问题，减少挑剔 (Focus on core issues, less nit-picking)

Your goal as a reviewer should be to help with core issues, such as bugs, architectural problems, structural problems or problems that will lead to maintainability issues.

作为审阅者，您的目标应该是帮助解决核心问题，例如错误，体系结构问题，结构性问题或会导致可维护性问题的问题。

Obviously, if you see typos, badly named variables or styling issues, you might also point that out. Still, this is not your main tasks and, understandably, over discussing minor issues isn’t valuable to code authors.

显然，如果您看到拼写错误，变量命名错误或样式问题，也可能会指出这一点。尽管如此，这不是您的主要任务，可以理解的是，讨论次要问题对代码作者而言并不重要。

使用评论清单 (Use a review checklists)

Another code review best practice is to use a systematic approach for code reviews. A code review checklist can speed-up and improve your code review performance. Instead of making one from scratch, download a ready-made list and customize it to fit your team’s practices and your needs. Be sure to look for a checklist that is tailored towards your technology stack.

另一个代码审查最佳实践是使用系统的方法进行代码审查。代码审查清单可以加快并提高代码审查性能。无需从头开始，只需下载一个现成的列表并对其进行自定义即可适合您团队的实践和您的需求。确保寻找适合您技术堆栈的清单。

代码审查最佳做法清单 (Code review best practices checklist)

Now you know all the code review best practices to make the most out of code reviews. If you enjoyed this post, consider subscribing to my email list.

现在您知道了所有代码审查最佳实践，可以最大程度地利用代码审查。如果您喜欢这篇文章，请考虑订阅我的电子邮件列表。

I prepared an exclusive Code Review e-Book for my e-mail subscribers to help you remember the code review best practices. I also added other great insights and summaries about code reviews. Get the 12 page insights to code reviews now. Not a subscriber yet? Just sign-up.

我为我的电子邮件订阅者准备了独家的代码审查电子书，以帮助您记住代码审查的最佳做法。我还添加了有关代码审查的其他出色见解和摘要。立即获取12页见解以编写代码评论。还没有订阅者吗？只需注册即可。

是否需要更多有关代码审查的信息？ (Want more on Code Reviews?)

Check out proven code review best practices, learn about which code review pitfalls you should avoid, and also how to boost your code review value with great feedback.

查看经过验证的代码审查最佳实践，了解应避免的代码审查陷阱，以及如何通过大量反馈提高代码审查价值。

To stay in the loop and never miss a blog post, sign-up to my email list and get the exclusive code review e-book. You can request the Code Review e-Book here.

为了保持循环状态，并且永远不会错过任何博客文章，请注册我的电子邮件列表并获取独家代码审查电子书。 您可以在此处索取《代码审查》电子书。

你在推特上找到我 (You find me on Twitter)

Let's connect on Twitter to discuss software engineering topics and code reviews there.

让我们在Twitter上连接以讨论软件工程主题和代码审查。

Originally published at https://www.michaelagreiler.com on May 2, 2019.

最初于 2019年5月2日 发布在 https://www.michaelagreiler.com 。

翻译自: https://www.freecodecamp.org/news/proven-code-review-best-practices/