Member-only story
How To Perfect Your Pull Requests
Streamline the code review process — for yourself and the reviewer
You’re sitting looking at the pull-request (PR) creation page, have you done everything you can to make the PR a success?
Any changes you make at this stage aren’t going to be anything special in their own right. If you’re making big changes at this point, something has gone wrong earlier in the process.
However, these final steps are important — for the health of the code base, as well as for your colleagues’ opinions of you. I think of this step like polishing a car; the bulk of the work is done when washing the car, but what makes it really shine is the polish at the end.
Self-Review the PR
Most platforms will present you with a diff when you’re creating your PR, I always use this to do one last sweep of my code.
Reviewing your own code is invaluable. It allows you to take a holistic view of your own work and see if you can improve it further. It’s also an excellent chance to spot mistakes such as typos or leftover debug code.
I’d say 80% of the time, I find something to improve upon. Usually they’re small things — perhaps a better naming for a particular test case, a tweak to update the documentation, or some small readability improvements in the code.
It’s also a good chance to check you’ve satisfied the acceptance criteria for the story you’re working on.
Pull-Request Size
Before you raise your PR, take a look at the number of lines changed. If you’re raising a PR that contains hundreds of lines changed — or even worse over 1,000 — the chances are at least one of two things will happen:
- No one reviews the PR in any sort of timely manner, and you have to repeatedly chase colleagues to do so, as the task of reviewing a big PR is quite a daunting one.
- Your colleagues will skim read very quickly and then approve the PR — either because they don’t have time to review such a big PR, or they simply can’t comprehend everything going in the PR due to its size.
