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.
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.
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!
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:
- Reviewing your own PR first
- Adding a description of what you want reviewed first
- 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! 🙂