git拉取请求_有效拉取请求审核的技巧

git拉取请求

Hi there — I’m Kaleb McKelvey, a full-stack engineer on the Content Engineering team within Disney Streaming Services (DSS). We build, support, and maintain tools such as the custom Content Management System (CMS) that empowers our editors to program and schedule content displayed within Disney+.

嗨，我是Kaleb McKelvey，迪士尼流媒体服务(DSS)内容工程团队的全职工程师。 我们构建，支持和维护诸如自定义内容管理系统(CMS)之类的工具，该工具使我们的编辑者可以对在Disney +中显示的内容进行编程和安排。

As we create new product features, we strive to implement them with team coding standards, industry best practices, top performance, and user experience in mind.

在创建新产品功能时，我们会努力在实现团队编码标准，行业最佳实践，最佳性能和用户体验的前提下实施这些功能。

We achieve this through a forcing function of reviewing each others’ code, which allows our team to collaborate and learn from each other along the way!

我们通过强制查看彼此的代码的功能来实现这一目标，该功能使我们的团队能够在此过程中相互协作并互相学习！

代码审查值得吗？ (Are Code Reviews Worth it?)

Engineering teams must decide if taking the time to review code is worth it. Why? Because time will be lost from completing feature work or bug fixes. Instead, developers use that time to evaluate the cleanliness, naming, architecture, and tests for code before it’s ready for release.

工程团队必须决定花时间检查代码是否值得。 为什么？ 因为完成功能工作或错误修复会浪费时间。 取而代之的是，开发人员会在准备发布之前，利用这段时间评估代码的整洁性，命名，体系结构和测试。

At DSS, we strongly believe code reviews are worth the time, as they bring two great benefits to the table.

在DSS，我们坚信代码审查是值得的，因为它们为表带来了两个巨大的好处。

好处1：代码质量 (Benefit 1: Code Quality)

When developers work on a feature, there is a self-serving bias to complete the ticket before the end of each sprint.

当开发人员使用某项功能时，存在一种自我服务的偏见，需要在每次冲刺结束之前完成票证。

Self-serving bias isn’t a negative; it just means we are human.

自我服务的偏见不是负面的； 这只是意味着我们是人类。

The rush caused by a sprint ending can lead to adding TODO comments or ignoring a code convention (or two), leaving code in a suboptimal state.

由sprint结束引起的匆忙可能导致添加TODO注释或忽略代码约定(或两个)，从而使代码处于次优状态。

Due to this bias, having another set of eyes on the code we’ve written forces us to maintain high code quality. Chances are if we don’t write clean, correct, standards, based code, we’ll be asked to make changes by our reviewer.

由于这种偏见，我们对编写的代码有另一番看法，这迫使我们保持较高的代码质量。 如果我们不编写整洁，正确，基于标准的代码，则很有可能会要求我们的审阅者进行更改。

For competitive developers, it can even be a fun challenge to attempt to author code that receives no comments for changes.

对于有竞争力的开发人员，尝试编写未收到任何更改注释的代码甚至可能是一个有趣的挑战。

Pull request, stamped ✅, merged. The dev life equivalent of a perfect dunk contest score.

拉取请求，加盖✅，合并。 开发者生活相当于扣篮大赛的完美成绩。

Whether we are the reviewer or reviewee, it’s imperative to remember that even though the code was written by an individual dev, engineering is a team effort. Thus, the code belongs to all of us.

无论我们是审阅者还是受审者，都必须记住，即使代码是由单个开发人员编写的，工程也是团队的努力。 因此，代码属于我们所有人。

That mindset — us vs. the bugs — gives each team member permission to find issues early in feature development.

这种思维方式( 我们与错误)使每个团队成员都有权在功能开发的早期发现问题。

One of my favorite videos on that topic can be watched below:

下面是我最喜欢的关于该主题的视频之一：

演示地址

https://www.youtube.com/watch?v=jtXgNTnVJUUhttps://www.youtube.com/watch?v=jtXgNTnVJUU

Benefit 2: Knowledge and Context Sharing

好处2：知识和上下文共享

Product features and the code required to implement them both grow over time.

产品功能和实现它们所需的代码都随着时间的推移而增长。

It’s common that code we have reviewed becomes part of a future feature assigned to us (code déjà vu) — wouldn’t it be nice to already have an idea of how it works? Additionally, what if we learned about the new question mark syntax (Optional Chaining) we saw during the review?

我们审查过的代码成为分配给我们的将来功能的一部分(代码déjàvu)是很常见的-已经对它的工作原理有所了解不是很好吗？ 此外，如果我们了解到在审核期间看到的新问号语法( 可选链接) ，该怎么办？

With both of the contexts now shared, we’re in great shape to start enhancing the previous feature in the next sprint, regardless of the ticket’s assignee.

现在，在共享了两个上下文的情况下，无论票证的受让人如何，我们都处于良好的状态，可以开始增强下一个sprint中的上一个功能。

This wonderful opportunity to grow, learn or teach leads to an open culture where we are always learning from each other.

这种发展，学习或教导的绝妙机会导致了一种开放的文化，我们一直在彼此学习。

Convinced on the power of code reviews? Let’s talk about how to do them effectively!

相信代码审查的力量？ 让我们来谈谈如何有效地做到这一点！

有效代码审查的技巧 (The Art of Effective Code Reviews)

Code reviews can be done in various steps and with varying degrees of detail. The project itself provides the level of code scrutiny.

可以通过不同的步骤以不同的步骤完成代码审查。 该项目本身提供了代码审查级别。

The general approach outlined below is a good baseline to help teams become more effective at code reviews and maintain higher code quality.

下面概述的一般方法是一个很好的基准，可以帮助团队提高代码审查效率并保持更高的代码质量。

There are two potential downsides to reviewing code. First, it takes developers, especially for large or complex changes, significant time to complete. Second, code reviews can become entrenched in long comment thread discussions on the best way to implement X or required changes to make from reviewers.

审查代码有两个潜在的弊端。 首先，这需要开发人员(尤其是对于大型或复杂更改)花费大量时间才能完成。 其次，代码审查可能会在冗长的注释线程讨论中根深蒂固，以讨论实现X的最佳方法或需要由审阅者进行的更改。

We can help ensure discussions happen on the right topics with the help of a few tools and agreed-upon conventions.

我们可以借助一些工具和已达成共识的约定，帮助确保在正确的主题上进行讨论。

自动化小事情以节省代码审查的时间 (Automating the Little Things to Save Time in Code Reviews)

The tools below are for the web development realm, but many tools exist for different tech stacks.

下面的工具用于Web开发领域，但是针对不同的技术堆栈存在许多工具。

Linting / Check Styles

整理/检查样式

We can save time by utilizing static code analyzers (like ESLint, Stylelint, or even SonarQube) that automatically check for and even fix bad practices. For example, making sure we remove all unused imports from a file.

我们可以利用静态代码分析器(例如ESLint，Stylelint甚至SonarQube)来节省时间，这些分析器可以自动检查甚至纠正不良做法。 例如，确保我们从文件中删除所有未使用的导入。

By having our code peer-reviewed during development, common issues are able to be fixed prior to code review. Further, we don’t have to look for those common issues as a code reviewer.

通过在开发过程中对我们的代码进行同行评审，可以在代码评审之前解决常见问题。 此外，我们不必作为代码审查者来寻找那些常见的问题。

Prettier Formatter formats code automagically on save for us too, helping avoid discussions about where new lines should be in a method header.

对于我们来说，Prettier Formatter也会自动格式化代码，从而有助于避免讨论方法标题中的新行。

Team Standards

团队标准

Static code analyzers make a huge difference in maintaining consistent and high-quality code bases; although, they can’t catch everything.

静态代码分析器在保持一致和高质量的代码库方面有很大的不同。 虽然，他们无法捕捉到一切。

That’s where we as responsible developers come in. We bring our different experiences, best practices, and favorite paradigms to keep the code up to par. Of course, with different opinions, we sometimes need to make team decisions on new conventions to follow.

这就是我们作为负责任的开发人员加入的地方。我们带来了不同的经验，最佳实践和喜欢的范例，以使代码保持一致。 当然，有不同的意见，有时我们需要根据新的约定制定团队决策。

How do we do this within the DSS Content Engineering team?

我们如何在DSS内容工程团队中做到这一点？

It generally starts with discussions about a new design pattern or paradigm introduced on a pull request with everyone chiming in. If it’s tough to come to a consensus over text — we talk it over on video call to make a final decision- weighing the different options together. If it’s decided that we follow a new paradigm or standard going forward, we add it to our documented code conventions and then use that for future development efforts.

通常首先讨论在拉动请求中引入的新设计模式或范例，每个人都参与进来。如果很难就文本达成共识，我们将通过视频通话进行讨论以做出最终决定，权衡不同的选择一起。 如果决定遵循新的范例或标准，则将其添加到已记录的代码约定中，然后将其用于将来的开发工作。

This is important because once the initial discussion concludes, those new patterns can make their way through code review with no issues. Like with automated analysis, such practices save reviewers’ time.

这一点很重要，因为一旦初步讨论结束，这些新模式就可以通过代码审查顺利进行。 与自动分析一样，这种做法可以节省审阅者的时间。

Now that we have two ways to optimize code reviews, we are ready to talk about the steps to review a pull request.

现在，我们有两种优化代码审查的方式，我们准备讨论审查请求请求的步骤。

有效的代码审查清单 (Effective Code Review Checklist)

Having a general process to follow gives the ability to review code in a methodical, thorough way. A checklist helps with this portion of the review process.

有一个通用的流程可以使您有条理，全面地审查代码。 清单将帮助您完成审核过程的这一部分。

Checklists keep us on track to complete each step in a process-driven manner, in the same order, every time. It’s also encouraged to comment, ask questions, or make suggestions throughout the code review checklist.

清单使我们始终按流程驱动方式，以相同顺序完成每个步骤。 在整个代码审查清单中，也建议对其进行评论，提出问题或提出建议。

Three important items can help to put team members in the right mindset before starting:

在开始之前，三个重要的事项可以帮助使团队成员正确地思考：

1. Be respectful and open-minded

   尊重和开放

2. Ask, collaborate, and learn
   询问，合作和学习
3. The goal is to make suggestions only when it makes the codebase better
   目标是仅在使代码库更好时提出建议

After that quick reminder, I follow these steps:

快速提醒之后，请按照以下步骤操作：

1. Review ticket(s) and understand the feature being asked for
   查看票证并了解所要求的功能
2. Take a few minutes to think how it could be done in the codebase (sometimes this requires looking through the current code)
   花几分钟时间思考如何在代码库中完成此操作(有时这需要查看当前代码)

3. Read the PR Description (many times we include high-level changes here)

3.阅读PR说明(很多时候我们在此处包括高级更改)

4. Read through the code to understand the changes and how it implements the feature

4.通读代码以了解更改及其实现功能的方式

• Does this fit our architecture well?
  这是否适合我们的架构？
• Does the data flow make sense?
  数据流有意义吗？
• Does it meet the AC on the ticket?
  它符合机票上的空调吗？
• Are there potential race conditions?
  有潜在的比赛条件吗？

5. <Insert Tech Stack> best practices

5. <插入技术堆栈>最佳实践

• Are we using the right feature of this language or library to implement this?
  我们是否使用这种语言或库的正确功能来实现这一目标？
• Is there a better way or best practice for this? Are we following it?
  是否有更好的方法或最佳做法？ 我们在关注吗？
• Are we avoiding anti-patterns?
  我们要避免使用反模式吗？

6. Tests (unit/integration/E2E)

6.测试(单元/集成/端到端)

• Are we testing the happy paths?
  我们在测试幸福的道路吗？
• Are we handling bad data or unexpected paths?
  我们是在处理不良数据还是意外路径？
• Edge cases — are we handling those?
  边缘案例-我们在处理这些案例吗？

结语 (Wrapping Up)

On our team and at DSS, we win as a team. We collaborate, ask for and offer help, and continuously raise the bar in our codebases.

在我们的团队和DSS，我们以团队的方式获胜。 我们合作，寻求并提供帮助，并不断提高我们代码库中的标准。

Code reviews have been an important key component of keeping the quality and patterns in our applications consistent, and as a developer, taking the time to code review effectively can make a huge difference over the lifespan of that product.

代码审查一直是保持应用程序质量和模式一致的重要关键组成部分，作为开发人员，花时间有效地进行代码审查可以在该产品的生命周期中产生巨大的影响。

Thank you for reading!

感谢您的阅读！

翻译自: https://medium.com/disney-streaming/the-art-of-effective-pull-request-reviews-376d05ce3ad4

git拉取请求