微软代码审查工具

Have you ever wondered how one of the largest software companies world wide ensures high quality code through code reviewing?

您是否想过全球最大的软件公司之一如何通过代码审查来确保高质量的代码？

So did I. That’s why together with my colleagues at Microsoft, we investigated how code reviews are done at our company. Is it a common practice? Are developers required to do code reviews? And which tools do they use?

我也是。这就是为什么我们与Microsoft的同事一起调查了公司中代码审查的方式。 这是常见的做法吗？ 开发人员需要进行代码审查吗？ 他们使用哪些工具？

Let’s find out in this post, which is part of a larger blog post series about code reviewing.

让我们在这篇文章中找到答案，它是有关代码审查的更大的博客文章系列的一部分。

To begin with, let me give you some key information about Microsoft. Microsoft has around 140,000 employees. Approximately 44% of them, that means over 60,000 employees, are engineers. Several products such as Office, Visual Studio or Windows are developed by thousands of engineers that work on the same code base simultaneously.

首先，让我为您提供有关Microsoft的一些关键信息。 微软拥有约14万名员工 。 其中大约44％，即超过60,000名员工是工程师。 成千上万的工程师同时使用相同的代码库来开发Office，Visual Studio或Windows等几种产品。

I say all this to give you some context and perspective of what it means to coordinate and manage the software development process. As you can imagine, it is a non trivial task to ensure code developed by different sub teams actually works perfectly together. And code reviews play a big role at Microsoft to allow smooth collaboration at such a large scale.

我说这些都是为了给您一些上下文和观点，以协调和管理软件开发过程。 可以想象，确保不同子团队开发的代码可以完美地协同工作是一项不小的任务。 而且，代码审查在Microsoft中扮演着重要的角色，以允许如此大规模的顺利协作。

Microsoft的代码审查是开发过程中不可或缺的一部分 (Code reviews at Microsoft are an integral part of the development process)

One of the important facts when it comes to code reviews at Microsoft is that it is a highly adopted engineering practice. Thousands of engineers perceive it as a great best practice. And most high-performing teams spend a lot of time doing code reviews.

在Microsoft进行代码审查时，重要的事实之一是它是一种被广泛采用的工程实践。 成千上万的工程师认为这是一个很好的最佳实践。 而且大多数高性能团队都花大量时间进行代码审查。

At Microsoft, code reviewing is a highly adopted engineering practice and perceived as a great best practice. Click To Tweet.

在Microsoft，代码审查是一种高度采用的工程实践，被认为是最佳的实践。 单击“鸣叫” 。

在Microsoft调查代码审查 (Investigating code reviews at Microsoft)

Because code reviews play such an important role in the Microsoft development process, it was an ideal target for us to dig deeper and really understand the benefits and drawbacks of this practice. In a large scale study on code reviews at Microsoft, we interviewed, observed and surveyed more than 900 developers about their code review practices.

因为代码审查在Microsoft开发过程中起着如此重要的作用，所以它是我们深入研究并真正了解这种做法的利弊的理想目标。 在Microsoft进行的有关代码审查的大规模研究中，我们采访，观察和调查了900多名开发人员的代码审查实践。

Our aim was to understand how exactly code reviews are done at Microsoft, which challenges developers face while doing code reviews, and to distill which best practices they develop to overcome those challenges.

我们的目的是了解Microsoft如何进行精确的代码审查，这是开发人员在进行代码审查时面临的挑战，并提炼出他们开发的最佳实践来克服这些挑战。

您可以从Microsoft的代码审查实践中学到什么？ (What can you learn from code review practices at Microsoft?)

Most of the lessons learned are as valuable to smaller teams and organizations as they are for large teams and large organizations. In case your team does not do code reviews yet, I distilled our findings in a way that shows you the benefits of the practice. I also explain how the code review life cycle looks like so you can incorporate that practice in your own development process.

对于小型团队和组织而言，大多数经验教训对于大型团队和大型组织而言都同样有价值。 如果您的团队还没有进行代码审查，我以一种向您展示该实践的好处的方式总结了我们的发现。 我还将解释代码审查生命周期的样子，以便您可以将该实践纳入自己的开发过程中。

If your team already does code reviews, you can compare your practice with the code review practice at Microsoft. Does your code review lifecycle look different? In later posts, you learn from the challenges that arise doing code reviews and the best practices. With this information you can set out to see if your team already implements all the best practices I present and overcome challenges. But, let’s get started:

如果您的团队已经进行过代码审查，则可以将您的实践与Microsoft的代码审查实践进行比较。 您的代码审查生命周期看起来是否有所不同？ 在以后的文章中，您将从代码审查和最佳实践中遇到的挑战中学习。 有了这些信息，您就可以开始查看您的团队是否已经实施了我介绍的所有最佳实践并克服了挑战。 但是，让我们开始吧：

Microsoft工程师多久执行一次代码审查？ (How often do Microsoft engineers perform code reviews?)

In this study, 36% of the developers said they perform code reviews multiple times a day. Another 39% of the developers said they do code reviews at least once per day. 12% do code reviews multiple times a week, and only 13% said they did not do a code review in the past week.

在这项研究中，有36％的开发人员说他们一天执行多次代码审查。 另有39％的开发人员表示，他们每天至少进行一次代码审查。 12％的人每周进行多次代码审查，只有13％的人说他们在过去一周未进行代码审查。

This means that developers at Microsoft spend a significant amount of their time on code reviews. So it is important to make sure that this time spent is worthwhile. But, which benefits does code reviewing provide?

这意味着Microsoft的开发人员将大量时间花费在代码审查上。 因此，重要的是确保这段时间是值得的。 但是，代码审查有哪些好处？

代码审查有哪些好处？ (Which benefits does code reviewing provide?)

The most important reasons developers mentioned as benefits of code reviews are to improve the code quality and to find defects in the code. Another important benefit of code reviews is knowledge transfer.

开发人员提到代码审查的好处的最重要原因是提高代码质量并发现代码中的缺陷。 代码审查的另一个重要好处是知识转移。

Knowledge transfer means that team members that review each others code, become familiar with a larger part of the code base. But, it also means that best practices are developed within the team. Another advantage is that new team members and junior developers can learn and improve their coding skills while reviewing or getting feedback.

知识转移意味着互相检查代码的团队成员会熟悉代码库的大部分。 但是，这也意味着在团队内部开发了最佳实践。 另一个优势是，新团队成员和初级开发人员可以在查看或获得反馈的同时学习和提高他们的编码技能。

If developers discuss alternative solutions during code reviews, it not only improves the code base, but has also a learning effect for all involved. Learning, mentoring and self-improvement are therefore all reasons code reviewing is perceived as such a beneficial practice at Microsoft.

如果开发人员在代码审查期间讨论替代解决方案，则不仅会改善代码库，而且对所有相关人员都有学习作用。 因此，学习，指导和自我完善是所有将代码审查视为Microsoft有益实践的原因。

Developers do code reviews to improve the code, to find defects, but mostly to increase the knowledge transfer amongst team members and for the learning effects. Click To Tweet.

开发人员进行代码审查以改进代码，查找缺陷，但主要是为了增加团队成员之间的知识传递并提高学习效果。 单击“鸣叫” 。

但是开发人员通常如何进行代码审查？ (But how does a developer typically do code reviews?)

Code reviews can be performed in many ways. Sometimes, it is as informal as one developer walking over to another developer’s desk to look at some code together. Other times, teams review code together in groups. But the most likely scenario you will encounter for code reviews at Microsoft is that code reviews are done with the help of tools.

代码审查可以通过多种方式执行。 有时，这就像一个开发人员走到另一个开发人员的办公桌前一起看一些代码一样非正式。 有时，团队会一起检查代码。 但是，在Microsoft进行代码审查时，最有可能遇到的情况是代码审查是借助工具完成的。

Microsoft的代码审查通常是通过内部工具完成的 (Code reviews at Microsoft are most often done via an internal tool)

There is a wide variety of code review tools available, and at Microsoft teams are free to choose their tooling. In 2016, 89% of the developers indicate to use the CodeFlow code review tool. I will explain more about this code review tool at Microsoft later. Since then, and with the rise of Git, the tooling landscape has changed. I’ll add updated numbers as soon as they become available. But, let us consider a typical review situation:

有多种代码检查工具可用，并且Microsoft团队可以自由选择其工具。 在2016年，89％的开发人员指示使用CodeFlow代码审查工具。 稍后，我将在Microsoft上解释有关此代码检查工具的更多信息。 从那时起，随着Git的崛起，工具领域发生了变化。 只要有更新的号码，我就会立即添加。 但是，让我们考虑一个典型的审查情况：

Let’s imagine a developer at Microsoft, and let us call her Rose. Rose just finished a part of a feature and now wants feedback from her peers.

让我们想象一下Microsoft的一名开发人员，让我们称她为Rose。 Rose刚刚完成了功能的一部分，现在希望获得同行的反馈。

Rose如何在Microsoft启动代码审查？ (How does Rose start a code review at Microsoft?)

Well, as said, Rose is ready to get some feedback. Therefore she first prepares the code for review. This step includes that she opens the code review tool, that allows her to preview the code change. The code review tool performs some diffing tasks that help Rose to see exactly which changes she has done.

好了，正如所说的，Rose准备得到一些反馈。 因此，她首先准备代码进行审查。 此步骤包括她打开代码检查工具，使她可以预览代码更改。 代码检查工具执行一些区分任务，以帮助Rose准确查看她所做的更改。

After carefully reviewing those changes, she prepares a small note that tells the reviewers what she did and why she did that. This note helps the reviewers to understand the purpose of the code change and its motivation. Now the code is ready to be sent to the reviewers.

在仔细检查了这些更改之后，她准备了一条小纸条，告诉审阅者她做了什么以及为什么这么做。 本说明可帮助审阅者了解代码更改的目的及其动机。 现在，可以将代码发送给审阅者了。

Rose如何选择合适的代码审阅者？ (How does Rose select the right code reviewers?)

Many experienced developers know who should be on the code review. Nevertheless, for people new on the team, or for new areas of work the selection can be a bit more tricky. If Rose does not know whom she should add, she would either look at the team policies or ask her colleagues. She can also use a recommendation feature of the code review tool that helps select reviewers based on experience and knowledge with the code base.

许多经验丰富的开发人员都知道谁应该参加代码审查。 但是，对于团队中的新成员或新的工作领域，选择起来可能会比较棘手。 如果罗斯不知道应该添加谁，她可以查看团队政策或询问同事。 她还可以使用代码审查工具的推荐功能，该功能可帮助您根据经验和对代码库的了解来选择审查者。

谁是相关的审稿人？ (Who are relevant reviewers?)

Rose selects reviewers that she thinks can contribute their knowledge to this piece of code. The reviewers are often other developers, but can also include other stakeholders, such as dev-ops engineers, UI experts, or also managers. Some reviewers are selected for their expertise, others are selected in order to stay informed about a coming change.

Rose选择了她认为可以为这段代码贡献知识的审稿人。 审阅者通常是其他开发人员，但也可以包括其他利益相关者，例如dev-ops工程师，UI专家或经理。 选择一些审阅者是因为他们的专业知识，因此选择其他审阅者是为了随时了解即将到来的变更。

Rose要求同​​龄人提供反馈 (Rose requests feedback from her peers)

Once everybody is selected, Rose sends out the code review (by pressing the send button ?). The code review tool sends notification automatically to inform everybody that a code review has been created. Notifications are sent to all reviewers. But, often additional parties, such as managers or product managers of other teams, are also added to the notification list, and are automatically informed for each review. Those notifications allow them to stay in the loop. They are not required to perform the review.

一旦选择了每个人，Rose就会发送代码审查(按“发送”按钮？)。 代码审查工具会自动发送通知，以通知所有人已创建了代码审查。 通知将发送给所有审阅者。 但是，通常还会将其他方(例如其他团队的经理或产品经理)也添加到通知列表中，并为每次审阅自动通知他们。 这些通知使他们能够停留在循环中。 他们不需要执行审核。

接收反馈是一个反复的过程 (Receiving feedback is an iterative process)

Once Rose’s colleagues have time, they will look at the code review. Each reviewer can annotate the code and add comments. Once finished commenting, the reviewer sends the annotated code back to Rose. Rose can now work on the comments and prepare a new improved version of the code.

一旦Rose的同事有时间，他们将查看代码审查。 每个审阅者都可以注释代码并添加注释。 完成评论后，审阅者会将带注释的代码发送回Rose。 Rose现在可以处理注释并准备代码的新改进版本。

Reviewers normally look for things like: does the code look bug free? Is there an architectural problem? Are there minor issues such as missing comments, spelling mistakes? Not all comments are equally valuable. But, there are several best practices to boost the value of code review comments.

审阅者通常会寻找类似的东西：代码看起来没有错误吗？ 有建筑上的问题吗？ 是否有一些小问题，例如缺少评论，拼写错误？ 并非所有评论都同样有价值。 但是，有几种最佳实践可提高代码审查注释的价值。

罗斯准备了代码的新改进版本 (Rose prepares a new improved version of the code)

Rose works on the feedback by fixing and addressing the suggestions. If Rose sees that there are some misconceptions or other contentious issues, she might walk over to a colleague to discuss this in person. That’s sometimes easier and more personal than through the tooling.

Rose通过修正和解决建议来处理反馈。 如果罗斯发现存在一些误解或其他有争议的问题，则可以走到同事那里亲自讨论。 这有时比通过工具更容易，更个性化。

Anyway, once she finished working on all the feedback, she sends a new version of the code to the reviewers. That new improved version is called a revision.

无论如何，一旦她完成了所有反馈，便将新版本的代码发送给审阅者。 该新的改进版本称为修订版。

If needed, she will receive further feedback. Whether or not this cycle continues for a few times depends on the type of change and its quality. For simple and small code changes, often only one code review revision is needed. For other more complex changes or changes in problematic code, several iterations might be necessary.

如果需要，她将收到进一步的反馈。 此循环是否持续几次取决于更改的类型及其质量。 对于简单和小的代码更改，通常只需要一个代码审阅修订。 对于其他更复杂的更改或有问题的代码更改，可能需要几次迭代。

It is totally normal, and partly desirable, that this code review feedback cycle sparks some discussions between the author and the code reviewers.

这段代码审阅反馈周期引发作者和代码审阅者之间的某些讨论是完全正常的，部分是可取的。

所有审阅者都批准并Rose检入代码 (All reviewers approve and Rose checks-in the code)

After this review cycle, reviewers mark the code as okay, and Rose can finally check-in the code into the common code base.

在此审查周期之后，审查者将代码标记为可以，并且Rose最终可以将代码检入通用代码库。

Some teams have policies that allow the developer to check-in the code before an actual review is completed. This is normally restricted to small and trivial changes, in order to allow asynchronous reviews and to speed-up development.

有些团队制定了一些政策，允许开发人员在实际审核完成之前签入代码。 通常，这仅限于微小的变化，以便允许异步审核并加快开发速度。

All steps I describe are part of a typical code review life cycle at Microsoft and are performed by all teams. Depending on the team’s policies, teams are more strict or rigorous for each of the steps.

我描述的所有步骤都是Microsoft典型代码审查生命周期的一部分，并由所有团队执行。 根据团队的政策，团队对每个步骤的要求都更加严格或严格。

并非所有团队都一样 (Not all teams are the same)

As you can imagine, not all 60,000 engineers, and not all of the thousands of teams do the same. Some teams at Microsoft have additional steps or tools they require during the code review life cycle. I want to give you a short overview of some additional steps that teams add to the code review process.

可以想象，并不是所有的60,000名工程师，也不是成千上万的团队都这样做。 Microsoft的某些团队在代码检查生命周期中需要其他步骤或工具。 我想简要介绍一下团队在代码审查过程中添加的一些其他步骤。

代码审查，包括测试结果 (Code reviews including test results)

The least what you want is to waste time by reviewing “automatic detectable” buggy code. I mean, if you could run automated tests and realize that the code does not work as expected, then, that’s what you should do: Run the tests before the review.

您最想要的是通过检查“自动检测”的错误代码来浪费时间。 我的意思是，如果您可以运行自动化测试并意识到该代码无法按预期工作，那么这就是您应该做的：在审查之前运行测试。

That’s why some teams require test results to be submitted with each code review. This way nobody can forget about running the tests. And it assures that the tests have actually run and passed for the given code change.

这就是为什么一些团队要求在每次代码审查时都提交测试结果的原因。 这样，没有人会忘记运行测试。 并且可以确保测试确实针对给定的代码更改运行并通过。

Other teams went even a step further and configured the code review tool in such a way that for each code review a developer submits, a build is triggered. That build contains that exact change, and also starts a series of automated tests. The results of this build and these tests are attached to the code review. Configuring it this way, ensures that the code changes have been tested with the latest code changes from the common code base.

其他团队甚至更进一步，以这样的方式配置了代码审查工具：开发人员提交的每个代码审查都会触发构建。 该构建包含该确切的更改，并且还启动了一系列自动化测试。 此构建的结果和这些测试将附加到代码审查中。 通过这种方式进行配置，可确保已使用通用代码库中的最新代码更改对代码更改进行了测试。

代码审查，包括用户界面 (Code reviews including user interface)

If changes affect the user interface, it is also a smart idea to require the developer to submit a screenshot. That way the code reviewer can see the effects of the code change without running the code. Second, the code reviewer can spot discrepancies when running the code on her own machine.

如果更改影响用户界面，则要求开发人员提交屏幕截图也是一个好主意。 这样，代码审阅者可以在不运行代码的情况下看到代码更改的影响。 其次，在自己的计算机上运行代码时，代码审查者可以发现差异。

代码审查，包括静态分析 (Code reviews including static analysis)

Static analysis tools are only as good as their configuration, but, in terms of styling issues they can save a lot of time for code reviewers. Some teams at Microsoft use automated static and dynamic analysis tools as dedicated bot-reviewers. Those bots comment on code styling and other static issues. Thus, freeing up time for human code reviewers to perform more interesting tasks.

静态分析工具仅与它们的配置一样好，但是就样式问题而言，它们可以为代码审阅者节省大量时间。 Microsoft的某些团队使用自动化的静态和动态分析工具作为专用的bot审阅者。 这些机器人在代码样式和其他静态问题上发表评论。 因此，可以腾出时间让人工代码审阅者执行更多有趣的任务。

微软的代码审查工具 (Microsoft’s code review tool)

For many years, one of the de facto standards for code review at Microsoft was an internal tool called CodeFlow. This is a sophisticated code review tool that supports developers and guides them through all steps of a code review. CodeFlow helps during preparation of the code, automatically notifies reviewers, and has a rich commenting and discussion functionality.

多年来，Microsoft进行代码审查的事实上的标准之一是内部工具CodeFlow。 这是一个复杂的代码检查工具，可支持开发人员并指导他们完成代码检查的所有步骤。 CodeFlow在编写代码期间提供帮助，可自动通知审阅者，并具有丰富的注释和讨论功能。

CodeFlow is an UI heavy tooling, much like Word or PowerPoint, as you can see in the screenshot below.

如下面的屏幕截图所示，CodeFlow是类似于UI或Word的UI繁重工具。

CodeFlow的界面说明 (CodeFlow’s interface explained)

You can skip this if you want, but for all interested, I am walking you through the interface of CodeFlow. Looking at the screenshot, on the left (A) you see all affected documents.

如果需要，可以跳过此步骤，但是对于所有感兴趣的人，我将带您浏览CodeFlow的界面。 查看屏幕快照，在左侧(A)，您会看到所有受影响的文档。

Also on the left, you see (B) the list of reviewers assigned to the review as well as their status (e.g., signed-off or pending). The active document is shown in the editor (C ). At the bottom, you see (D) a list of comments for all documents.

同样在左侧，您会看到(B)分配给该评论的评论者列表以及他们的状态(例如，已签署或待审核)。 活动文档显示在编辑器(C)中。 在底部，您可以看到(D)所有文档的注释列表。

On the other hand, in the active document (F) is one single comment. This comment is connected to the concrete part of the code (i.e., one word in a line). Finally, at the top you see the overall status of the code review. In this case, completed. The numbers before signal the different revisions. In this review, there have been five revisions.

另一方面，在活动文档(F)中只有一个注释。 此注释连接到代码的具体部分(即，一行中的一个单词)。 最后，在顶部您会看到代码审查的总体状态。 在这种情况下，完成。 之前的数字表示不同的修订版本。 在此审查中，有五个修订。

评论功能 (Commenting functionality)

One of the nicest features of CodeFlow is its commenting functionality.

CodeFlow的最佳功能之一是其注释功能。

A code reviewer can select very precisely the parts of the code she wants to comment on. For example, a reviewer can even highlight just one or two characters in a line, instead of highlighting a whole row. Then, the reviewer can attach a comment to that selection.

代码审阅者可以非常精确地选择要注释的代码部分。 例如，审阅者甚至可以仅突出显示一行中的一个或两个字符，而不是突出显示整行。 然后，审阅者可以对该选择附加评论。

The code author or other reviewers are notified of this comment and can start a conversation in form of a thread around this comment.

通知该注释的代码作者或其他审阅者，并且可以围绕该注释以线程的形式启动对话。

讨论功能 (Discussion functionality)

This commenting functionality feels like commenting on social media platforms, such as Twitter or Facebook. Therefore, the commenting experience in CodeFlow feels very natural and allows rich conversations and discussions. Another nice perk is the possibility to assign a status to each of these comment threads. The status can, for example, be “won’t fix”, “resolved” or “open”.

这种评论功能就像在Twitter或Facebook这样的社交媒体平台上发表评论一样。 因此，CodeFlow中的评论体验非常自然，可以进行丰富的对话和讨论。 另一个不错的好处是可以为每个注释线程分配状态。 该状态例如可以是“无法修复”，“已解决”或“打开”。

代码审查修订之间的比较 (Comparison between code review revisions)

A helpful feature is the possibility to select two different revisions of the code review and compare the differences between that. This means that you can see exactly which changes the code review author has performed between one code review revision and another one. That’s super handy to track the progress of the review.

一个有用的功能是可以选择两个不同的代码审查版本，并比较两者之间的差异。 这意味着您可以准确地看到代码审查作者在一个代码审查修订版和另一个代码审查修订版之间进行了哪些更改。 跟踪审核进度非常方便。

代码审查分析工具 (Code review analytics tool)

Developers spend a substantial amount of their time performing code reviews at Microsoft. To ensure this time is well spent, Microsoft has its own code review analytics platform.

开发人员花费大量时间在Microsoft进行代码审查。 为确保充分利用这段时间，Microsoft拥有自己的代码审查分析平台。

This platform stores all code review data starting from the code under review, the developers involved in code reviews, to all comments of the developers. Even the code changes for each of the revisions can be traced back.

该平台存储所有代码检查数据，这些数据从受检查的代码，参与代码检查的开发人员到开发人员的所有注释开始。 甚至每个修订的代码更改都可以追溯。

This code review data is the base for several empirical studies on code reviews at Microsoft. It is also used by many product teams for tracking their productivity and to understand their own code review practices. Also, many of the insights I share in this blog post series about code reviews at Microsoft stem from studies and analyses that involved this code review data.

此代码审查数据是 Microsoft对代码审查进行一些实证研究的基础 。 许多产品团队还使用它来跟踪他们的生产率并了解他们自己的代码审查实践。 另外，我在此博客文章系列中分享的许多关于Microsoft代码审查的见解都源于涉及此代码审查数据的研究和分析。

微软代码审查的未来 (The future of code review at Microsoft)

With Micorosft’s engagement and acquisition of GitHub change was inevitable. The change is visible by the vast adoption of Git as a source control tooling within Microsoft for example. But, this also means that at Microsoft code reviewing in form of pull requests is on the rise.

随着Micorosft的参与和对GitHub的收购，变更是不可避免的。 例如，Microsoft广泛采用Git作为源代码控制工具，就可以看到这一变化。 但是，这也意味着在Microsoft，以请求请求形式进行的代码审查正在增加。

I’ll definitely plan to address code reviewing using pull requests at a later time.

我一定会在以后使用拉取请求解决代码审查问题。

下一步：代码审查挑战 (Coming up next: Code review challenges)

I will write about code review challenges in the next blog post. To stay in the loop and follow me on medium.

我将在下一篇博客文章中介绍代码审查挑战。 保持循环并在中等水平跟随我 。

Credit where credit is due:

信用到期的地方：

I would like to mention my wonderful colleagues at Microsoft and the University of Victoria that have been part of this study: Chris Bird, Jacek Czerwonka and Laura Macleod and Margaret-Anne Storey. I loved to work with you on this ♥

我想提及我和微软以及维多利亚大学的出色同事，他们是这项研究的一部分： 克里斯·伯德 ， 贾赛克 · 切尔旺卡和劳拉·麦克劳德和玛格丽特·安妮·斯托里 。 我很乐意与您合作♥

Originally published at www.michaelagreiler.com on March 27, 2019.

最初于2019年3月27日发布在www.michaelagreiler.com上。

翻译自: https://www.freecodecamp.org/news/how-code-reviews-work-at-microsoft-4ebdea0cd0c0/

微软代码审查工具