Higher Quality Pull Requests

3 minute read

Lately, I have been working on making sure my Pull Requests are of a higher quality. You may ask, well Alex: “What is a high quality Pull Request and how does this mythical creature look like?”

The definition of a high quality Pull Request can vary depending on the team and organisation but here are a few of tips from my own experience.

High Quality Pull Requests generally:

Are small and concise
Include tests as a deliverable when implementing new features or when changing existing behaviour
Include a short and clear description of the goal behind the PR
Include videos or images and ideally a demo of the feature, so engineers reviewing can see the culmination of the work, this is especially handy when working on frontend, mobile or anything that relies on user interaction.
Before and After screenshots, so engineers reviewing can visualize the changes you have implemented on the UI.
Focused on related changes, so don’t make changes in a class User when you’re working on a totally different unrelated problem domain. Take note on any improvements that can be made, create a ticket to tackle that work separately if possible.
Include short and descriptive commits.
If you have to add a TODO in your code for whichever reason, ensure there is an associated ticket so engineers can track that work.
If necessary provide rationale for why you decided to solve a problem in a specific manner, its pros and cons and why it makes sense to follow this approach in the short to long term.
Ensure you have reviewed the code yourself at least once before putting up the PR, visualising changes in the diff editor in your IDE can help spot any issues quickly.
Ensure code follows the teams or organisations standards.
Ensure you have manually tested the feature before asking anyone to review the change. If it is backend change, deploy it to a staging or dev environment and ensure the change works as expected.
Ensure you have taken time to think of all the edge cases, you don’t have to add them now but you have to be aware of them and be able to communicate them.
Ensure your run the same code commands that will run in your CI/CD pipeline locally, ideally before committing changes. For example, if during CI you run commands to check types, perform static code analysis, or if the code is formatted correctly you should probably run the same commands locally. This helps you catch any issues that might fail during CI/CD quickly so you don’t waste time.
Create the Pull Request but don’t post it yet. Take a walk, drink a cup of water and come back and verify if all is well. It’s amazing how taking a few minutes away from the computer can help you catch issues in your code and other areas you might need to improve.

Well, this are just some of the tips I have, try them out and see how they help you output higher quality Pull Requests.

What tips would you like to share? Let me know!