代码走查和代码审查
Code reviewing is an engineering practice used by many high performing teams. And even though this software practice has many advantages, teams doing code reviews also encounter quite a few code review pitfalls.
代码审查是许多高性能团队使用的一种工程实践。 尽管这种软件实践有很多优点，但是进行代码审查的团队也遇到了很多代码审查陷阱。
In this article, I explain the main code review pitfalls you should be aware of to ensure code reviewing does not slow your team down. Knowing which pitfalls and problems arise can help you to ensure a productive and effective code review experience. Those findings are based on a survey we conducted at Microsoft with over 900 participants.
在本文中，我将解释您应注意的主要代码审查陷阱，以确保代码审查不会使您的团队减速。 了解哪些陷阱和问题会帮助您确保产生高效的代码审查经验。 这些发现是基于我们在Microsoft进行的一项针对900多名参与者的调查得出的。
典型的代码审查过程 (A typical code review process)
A typical tool-based code review process looks roughly like this: Once the developer has finished a piece of code, they prepare the code for being submitted for review. Then, they select reviewers who are notified about the review. The reviewers then review the code and give comments. The author of the code works on those comments and improves and changes the code accordingly. Once everybody is satisfied, or an agreement is reached, the code can be checked into the code base.
典型的基于工具的代码审查过程大致如下：开发人员完成一段代码后，便准备要提交以供审查的代码。 然后，他们选择被通知有关评论的评论者。 然后，审阅者审阅代码并发表评论。 代码的作者处理这些注释，并相应地改进和更改代码。 一旦每个人都满意或达成协议，就可以将代码检入代码库。
In another post, I described how a typical code review process looks like at Microsoft.
在另一篇文章中，我描述了典型的代码审查过程在Microsoft的情况。
代码审查并不总是一个平稳的过程 (Code reviewing isn’t always a smooth process)
These steps read like a smooth process. But, like everything, in practice, things tend to be more complicated than anticipated. During the code review process there a quite a few pitfalls that can reduce the positive experience with code reviews for the whole team. If not done correctly, code reviewing can also take its tolls on the whole team’s productivity. So, let’s have a look at the difficulties and pitfalls of code reviews.
这些步骤读起来很顺利。 但是，实际上，就像一切一样，事情往往比预期的要复杂。 在代码审查过程中，有很多陷阱可以减少整个团队进行代码审查的积极经验。 如果执行不正确，代码审查也可能会损害整个团队的工作效率。 因此，让我们看一下代码审查的困难和陷阱。
The two main types of code review pitfalls are about the time spent on code reviews, and the value code reviews provide.
代码审查陷阱的两种主要类型是代码审查所花费的时间以及代码审查所提供的价值。
Be aware of code review pitfalls. Otherwise, code reviews can slow your team down. Click To Tweet
注意代码审查的陷阱。 否则，代码审查会拖慢您的团队。 点击鸣叫
等待代码审查反馈很痛苦 (Waiting for code review feedback is a pain)
One of the main pitfalls code authors face is to receive feedback in a timely manner. Waiting for the comments to come in and not being able to work on the code in the meanwhile can be a huge problem. Even though developers can pick up other tasks to work on, if the code review takes too long, it impacts the developer’s productivity and also the developer’s satisfaction.
代码作者面临的主要陷阱之一是及时接收反馈。 等待注释进入而无法同时在代码上工作可能是一个巨大的问题。 即使开发人员可以承担其他工作，但如果代码审查花费的时间太长，则会影响开发人员的工作效率以及开发人员的满意度。
But, why does the code review feedback take so long?
但是，为什么代码审查反馈需要这么长时间？
开发人员必须兼顾多项责任 (Developers have to juggle several responsibilities)
Well, code reviewing is not the only task the code reviewer has to perform. On the contrary, code reviewing — even though it can take a significant amount of time of a developer’s day-to-day work — is only one part of the responsibilities and tasks of a developer. So, it is very likely that the code reviewer is engaged in other activities and has to stop or finish those first before looking at the code review.
嗯，代码审查不是代码审查者必须执行的唯一任务。 相反，即使开发人员的日常工作可能要花费大量时间，代码审查也只是开发人员职责和任务的一部分。 因此，代码审查者很可能从事其他活动，并且必须先停止或完成那些活动，然后再查看代码审查。
If the timing is not ideal, and especially if the code reviewer hasn’t anticipated this change coming along, chances are, it takes a while before they look at the review. Remote teams also have to be aware of time differences. Otherwise, code reviews might even take longer.
如果时机不理想，特别是如果代码审阅者没有预料到会发生这种变化，那么很可能需要一段时间才能查看审阅。 远程团队还必须意识到时差。 否则，代码审查可能甚至需要更长的时间。
如果不将代码审查视为实际工作，则开发人员将面临问题 (Developers face problems if code reviews are not counted as actual work)
Time constraints are real, and they affect both, the code reviewer and the author of the code. Doing a proper code review takes time. If teams want developers to do code reviews but do not value or count the time developers spend on code reviews, this becomes a real problem.
时间限制是真实的，并且会影响代码审阅者和代码作者。 进行正确的代码审查需要时间。 如果团队希望开发人员进行代码审查，但不重视或不考虑开发人员花费在代码审查上的时间，那么这将成为一个真正的问题。
如果您不重视开发人员在代码审查上花费的时间，就无法期望获得高质量的代码审查。 点击鸣叫
不奖励代码审查工作和性能 (Not rewarding code reviewing efforts and performance)
It does not help to claim to value code reviews if you do not reward the effort developers spend on this task. Many companies focus on rewarding developers for the amount of code they write or the features they develop. This decreases the motivation and the ability of developers to do a good job helping each other (which includes code reviewing). Code review effort and performance should be a cornerstone for performance evaluation or promotion decisions.
如果您不奖励开发人员在此任务上花费的精力，那么声称对代码进行评估就无济于事。 许多公司专注于奖励开发人员编写的代码量或开发的功能。 这降低了开发人员做好彼此帮助的动力和能力(包括代码审查)。 代码审查工作和绩效应成为绩效评估或升级决策的基石。
If you want your team to do code reviews well, reward them for their work. Click To Tweet
如果您希望您的团队对代码进行良好的审查，则对他们的工作给予奖励。 点击鸣叫
社会因素和团队动力 (Social factors and team dynamics)
But waiting on a code review had not always to do with the lack of time or missing reward system. Due to its social character, delayed reviews can be due to insecurities or team dynamics. Especially if the code review is overwhelming, or if the reviewer is new to the code, doing a code review can be overwhelming:
但是等待代码审查并不总是与缺少时间或缺少奖励系统有关。 由于其社交性质，延迟审核可能是由于不安全感或团队动态所致。 尤其是如果代码审查不胜枚举，或者如果审查者是新来的代码，那么进行代码审查可能会很麻烦：
I’m expected to participate, but I’m not quite sure how. I’ll wait until someone else starts. — study participant
我预计会参加，但是我不确定如何参加。 我将等到其他人开始。 -研究参与者
大评论很难复习 (Large reviews are hard to review)
Another significant code review pitfall is large reviews. Imagine you are the reviewer, and you just got this review. You think, well, I am quickly going to look at that, but once you open the review, you see this large code change. Several files have been changed, and all changes tangle throughout the code base. What’s your first reaction?
另一个重要的代码审查陷阱是大型审查。 假设您是审阅者，而您刚刚获得了此审阅。 您认为很好，我很快就去研究一下，但是一旦您打开审阅，您就会看到这个巨大的代码更改。 几个文件已更改，所有更改在整个代码库中都缠在一起。 您的第一React是什么？
Probably: holy cow!
可能是：圣牛！
That’s right. That is exactly what we saw when analyzing thousands of code reviews. Not only does review time increase with the size of the code change, but also feedback quality decreases. Well, that’s probably understandable.
那就对了。 这正是我们在分析数千个代码审查时所看到的。 评审时间不仅随着代码大小的变化而增加，而且反馈质量也会下降。 好吧，这可能是可以理解的。
10 lines of code = 10 issues.
10行代码= 10个问题。
500 lines of code = “looks fine.”
500行代码=“看起来不错”。
Code reviews.
代码审查。
— I Am Devloper (@iamdevloper) November 5, 2013
— I Am Devloper(@iamdevloper) 2013年11月5日
Large code changes are just incredibly difficult to review. If, in addition, the code reviewer is not that familiar with the part of the code base the change took place in, reviewing can quickly become a nightmare.
大型代码更改非常难以审核。 此外，如果代码检查者对更改所基于的代码库部分不太熟悉，那么检查很快就会成为噩梦。
大代码审查很难审查。 评审的质量随着更改的大小而降低，从而限制了价值团队从代码评审中脱身的价值。 点击鸣叫
了解代码更改需要一些指导 (Understanding code changes needs some guidance)
Understanding code changes, and especially the motivation for a code change, is another code review pitfall many reviewers face. If there is no description explaining the purpose of the change, code reviewing becomes much harder. We saw in the study that if the code reviewer does not understand the code change, or if she is overwhelmed by the amount of change, she cannot give insightful feedback.
了解代码更改，尤其是代码更改的动机，是许多审阅者面临的另一个代码审阅陷阱。 如果没有说明来说明更改的目的，则代码审查将变得更加困难。 我们在研究中看到，如果代码审阅者不理解代码更改，或者如果她对更改量感到不知所措，那么她将无法提供有见地的反馈。
It’s just this big incomprehensible mess. Then you can’t add any value because they are just going to explain it to you and you’re going to parrot back what they say.
就是这么大的不可理解的混乱。 然后，您将无法添加任何价值，因为他们只会向您解释它，而您会模仿他们的话。
— interviewed developer13
—采访了developer13
没有获得有价值的反馈会降低开发人员从代码审查中获得的利益和动力 (Not getting valuable feedback decreases the developers’ benefit from and motivation for code reviews)
Without doubt, spending the time on code reviews and not getting useful feedback back is a problem. Even though the team might still benefit from the knowledge transfer, the developer’s motivation to do code reviews and the benefits from code reviews decrease when they do not get valuable feedback.
毫无疑问，将时间花在代码审查上并没有得到有用的反馈是一个问题。 即使团队仍然可以从知识转移中受益，但是当开发人员没有获得有价值的反馈时，他们进行代码审查的动机和代码审查的好处就会减少。
There are several reasons why reviewers do not or can’t give insightful feedback. It can be that the code reviewer did not have the right expertise. Another common reason is that the reviewer did not have enough time to look thoroughly through the change.
审稿人没有或无法提供有见地的反馈有多种原因。 可能是代码检查者没有适当的专业知识。 另一个常见原因是审阅者没有足够的时间来彻底了解更改。
Maybe the code reviewer does not understand the code. It can also be that the code reviewer does not know what issues to look for. Understanding what makes for valuable code review feedback and implementing best practices mitigates this pitfall.
也许代码审查者不理解代码。 也可能是代码审阅者不知道要查找什么问题。 了解什么能使有价值的代码审查反馈有效，并实施最佳实践可以减轻这种陷阱。
一旦主要的讨论是关于样式，就需要采取行动 (Once the main discussion is about styling, you need to act)
Another problem that can happen during a code review is called bikeshedding. Bikeshedding means that developers focus on smaller issues and start disputing minor issues and overlook the serious ones.
在代码审查期间可能发生的另一个问题称为Bikeshedding。 Bikeshedding意味着开发人员专注于较小的问题，并开始争论较小的问题，而忽略了严重的问题。
The reasons for that are manifold. Common behind the scenes challenges that lead to bikeshedding is that developers do not understand the code change or that they do not have enough time for the code reviews. Sometimes bikeshedding can be a sign that there are issues with the team dynamics.
原因是多种多样的。 导致脱机的幕后常见挑战是，开发人员不了解代码更改，或者他们没有足够的时间进行代码审查。 有时，骑车流失可能表明团队动力存在问题。
如果人们在代码审查期间对次要问题提出异议，则必须查看潜在问题。 时间压力，太大的评论，竞争？ 点击鸣叫
达成共识可能需要面对面的讨论 (Reaching consensus might need a face-to-face discussion)
Sometimes it can happen that it is hard to reach a consensus. This can occur between code reviewer and code author, or also between several code reviewers directly. Such situations must be handled carefully as team dynamics are closely connected to these happenings. Communication via tools and in written form can aggravate this problem. If there seems to be any tension, or contentious issues to discuss, switching to face-to-face (either in person or via a video call) might be a good idea.
有时可能很难达成共识。 这可以在代码审阅者和代码作者之间发生，也可以直接在多个代码审阅者之间发生。 由于团队动态与这些情况密切相关，因此必须谨慎处理这种情况。 通过工具和书面形式进行的交流会加剧这个问题。 如果似乎存在任何紧张关系或有待讨论的问题，那么(面对面或通过视频通话)面对面交流是一个好主意。
代码审查的好处胜于努力 (The benefits of code review outweigh the effort)
I hope this list of code review pitfalls did not change your mind about code reviews. Because, the good news is that if you are aware of the code review pitfalls and counteract them, code reviews are a very beneficial engineering technique. And, there are even more proven ways to work effectively with code reviews.
我希望这份代码审查陷阱清单不会改变您对代码审查的看法。 因为，好消息是，如果您知道代码审查的陷阱并加以弥补，那么代码审查是一种非常有益的工程技术。 而且，还有更多行之有效的方式来与代码审查一起使用。
代码审查最佳实践 (Code review best practices)
In the next blog post in this code review series, I show best practices to help to minimize the code review pitfalls and challenges and ensure your team gets the best out of the code review practice. So keep on reading. To be notified when I publish the next post, follow me on twitter.
在此代码审查系列的下一篇博客文章中，我将展示最佳实践，以帮助最大程度地减少代码审查的陷阱和挑战，并确保您的团队从代码审查实践中获得最大的收益。 因此，请继续阅读。 要在我发布下一篇文章时得到通知，请在Twitter上关注我。
I prepared an exclusive Code Review e-Book for my newsletter subscribers. So make sure you subscribe to my email list and secure your Code Review e-Book including a handy cheat sheet of code review best practices.
我为通讯订阅者准备了独家的Code Review电子书。 因此，请确保您已订阅我的电子邮件列表，并确保您的《代码审查》电子书安全，其中包括一份方便的代码审查最佳实践速查表。
Originally published at https://www.michaelagreiler.com on April 6, 2019.
最初于2019年4月6日发布在https://www.michaelagreiler.com 。
代码走查和代码审查
扫一扫
1625
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
