Pull requests have been around for a while now. As part of the agile process, they aim to reduce code smell, get opinions from other developers and keep the codebase consistent.
This is, of course, purely utopic. In reality, PR’s are big chunks of code that you are going to scroll through to look for mistakes.
The Downsides of Pull Requests
Lack of context
The main issue with a PR is the total lack of context. Most of the time, your pull request tool is going to show you the bits of code that changed and hide the unchanged lines. This hiding is removing the context that you need to have a full overview of the code.
You can of course see this hidden code, but it’s usually not that easy to read and tends to make it more confusing than it should be.
In the end, you can still detect code smell and bad practices, but you are not really able to tell if the code is going to work well! And this can be a way for bugs to be pushed.
Huge amount of code to review
A PR can feel like a long page on which you are just scrolling. And more you scroll and more you’ll lose attention as you’d like to go back to your tasks.
A PR is not a funny process, and if they are too long (and they quickly are) some reviewers are just going to lose their patience, quickly scroll through the PR and approve it.
Once again, this can lead to bugs and code smell in your codebase. And you don’t want that!
How to Improve Code Reviews?
I chose here to use the expression Code Review. The reason is that a PR should bring to a process larger than just scrolling on a page. It should be a process in which other developers are understanding and assimilate the new code instead of just hunting for bad practices.
Create PR’s early in the development process
The first improvement to the code review process is to create the pull requests early in the development process and mark them as WIP (Work in Progress).
By doing this way, you’ll be able to easily ask for early reviews from your teammates and allow them to understand the new feature at the same time as it’s developed. Also, reviewers will have less code to review at once and they’ll stay focused on each step of the PR.
Pull the branch and give it a go!
If the first improvement has been put in place, the reviewers should already have a better understanding of the feature. However, sometimes, the code is not enough to visualize the changes. So your reviewers may want to pull the branch and give it a try.
Trying the new solution could bring multiple benefits.
First, reviewers will visualize what changed and they’ll be able to talk about it on the behalf of the developer who made the changes. As part of a team, some managers expect each member to share knowledge, this includes what others are working on.
Also, in the case of a demo, if the developer who worked on the task cannot attend to it, one of the reviewers can easily take over the demo and already knows the topic.
Finally, having reviewers quickly test the new feature will save time to QA’s by giving the first step of testing.
Link the work item to the PR
This could sound basic, but having the work item (or task description) linked to the PR will make the context clearer. Reviewers can open it and read it before starting the review and will have a better idea of what this is about.
The more the merrier!
You may want multiple reviewers to review your code. And if you can have multiple profiles (Juniors, Mid-Ranges, Seniors) it’s even better!
Juniors can ask you questions about your new code, this could be a sort of mentoring and the whole team would benefit from it.
Mid-Ranges and Seniors could have different visions of good practices and a discussion could start to improve the global code quality.
It is also good to have different points of view in case one of the reviewers misses a mistake!
For me, a pull request can be as effective as it can be time-consuming depending on how the process is organized.
But by applying some simple improvements to them, it can improve the teamwork, create communication between the different team members and improve the whole codebase.
PR’s should not be neglected, they can be a very strong process.