Three Ways to Prepare Your Pull Request for a Great Review

Some software engineering teams use pull requests to perform code reviews. In a pull request (sometimes referred to as PR), you have the chance to get feedback or approval on your code and make any additional changes before merging your code.

The review process can be dependent on the personalities of reviewers, but I will describe the three ways I try and prepare my pull requests so that I can ensure that it is of the best quality before submitting it.

1. Review your own PR first

Try to take on the perspective of whoever might review your code. Do you have a mental checklist for what you think they might be looking for during the code review? For example, you can check for typos, formatting, or failing tests.

2. Add a description of what you prioritize in the review

When I am reviewing code, I find it helpful when the person who requested a review points out specific parts of the code they want me to look at more closely. Making note of a particular section you might want greater feedback on will help speed up the time it takes to receive a review. For example, if you are unsure of the way you mocked certain objects in your test, you can point that out!

3. Explain the changes made

Explaining why code changes were made along with what changes were made will help provide context to your reviewer. I find it better to provide some context than none at all. For example, if you are working in an open source repository and you submit a pull request, you can link the corresponding issue that was opened for the project.

You can improve your pull requests right now by:

1. Reviewing your own PR first
2. Adding a description of what you want reviewed first
3. Explaining why you made the changes you did

Let me know if you use any of these methods or share some other practices you follow before submitting your pull request! 🙂

Comments

[Waylon Walker]

Great tips!!

Have empathy for their time. Many open source projects get tons of prs that maintainers have to try to understand. They have to not only understand your change technically, but what it means for the project moving forward. Your features Are like a new puppy that the project will need to continue to support long after you are done with the PR.