Developers have been using Pull Requests to review code on branches before it reaches master for a very long time. However, this workflow is one of the most challenging and time-consuming parts of the software delivery process.

Every Pull Request comes with different challenges, which can happen before, during, or after the PR is open. In a previous article, we gave you 13 tips to make your PR easier to review. Today, we’ll cover how you can have a better PR workflow by solving 9 challenges you might face.

Before opening the PR 

Personnel bottlenecks

Problem:  To ensure that high-quality code gets merged into production, some teams only allow some developers to merge PRs. This is well-intentioned, but senior developers tend to get overburdened since they are more knowledgeable. Overwork also increases the likelihood of an error occurring during the review process.

Solution: Include everyone in the code review process. You can use the logic of pair programming in code reviews with senior and junior developers. Everyone will broaden their knowledge of the code base, and the reviews will serve as learning tools where junior developers can improve their skills.

Difficulties in reaching consensus

Problem: Developers sometimes struggle between defending their individual ideas and incorporating contributions different from their vision, either because they don’t agree with the project's direction or the way other developers wrote the code. In those cases, reaching a consensus is challenging.

Solution: Having a shared vision with a clear roadmap about the project's future direction will help developers reach consensus faster. Plus, you can show developers that different ways of writing code are not inherently wrong. If it doesn’t compromise the quality and understandability of the code and if it’s following the agreed coding standards, it should get accepted.

Too extensive Pull Requests

Problem: The more lines of code you need to check, the higher the chance you’ll overlook something. Plus, developers don’t usually thoroughly review big PRs, because they are time-consuming and easier to get lost. As such, it’s fair to say that the bigger the PR, the poorer the code review will be.

Solution: Make smaller and self-contained Pull Requests. Because the PRs are small, it’s easier for reviewers to understand the context and reason with the logic, so the review is quicker and more thorough, and the PR is easier to merge, leading to fewer merge conflicts.

When the PR is open

The code is hard to understand

Problem: Sometimes, developers write code in a way that makes it difficult to understand. If one developer writes unstructured and hard-to-maintain code that other developers cannot read, this will affect the speed of the code reviews and the overall team’s velocity.

Solution: Establish coding standards and guidelines for your code structure and logic. They’ll help your team ship faster and more often since they lead to lower code complexity and more elegant design solutions. Plus, with coding standards, any developer can examine any part of the code, understand it, and change it independently of when and who wrote it.

Lack of information and context on PRs

Problem: When a reviewer opens a PR, all they have is what the author gave him. When there’s insufficient information on the PR description, the reviewer loses the context of the code, making the code review less effective and more time-consuming.

Solution: You’ll save everyone time by providing as much context as possible in a relevant and informative PR description. The most helpful descriptions explain the what, how, and why and give additional information that might help the reviewer in the code review process. 

💡Check out tip #6 on how to make your PR easier to review.

A high volume of PRs

Problem: When there are many PRs and not enough people to review them promptly, it can lead to triaging and work prioritization problems. Plus, PRs that are not checked for a long time, while others change the project in terms of functionality, will make it harder to merge without conflicts.

Solution: Set a daily limit on the number of PRs your team can open, and optimize your review workflow. Start by identifying long-running Pull Requests, and check if they still need to be reviewed or if the work doesn’t make sense anymore.

After the PR is open

Lack of response from the author of the PR

Problem: The distributed nature of pull-based development means that a lack of responsiveness on behalf of the PR author hurts the entire code review process, making it slower than it should be.

Solution: Foster a culture where the PR author is ready to respond to comments once feedback starts appearing. By replying, the authors are helping everyone keep track of the feedback that has been seen and considered.

Merge conflicts

Problem: When two developers have made changes to the same set of lines of code, there is a conflict when merging, where the version controller doesn’t know which code to keep and which to discard.

Solution: You can avoid merge conflicts by improving your team’s communication. Use internal communication and project management tools to keep track of the changes and where in the codebase the developers are making them.

A lengthy review process

Problem: A typical PR workflow implies a lengthy series of reviews and tests before you officially deploy the code into production. The process aims to ensure code quality and an alignment between the functionality and the project’s vision.

Solution: Improve the speed of the PR reviews by committing small and often. Plus, ensure that your team understands the importance of code reviews and that they have enough time to perform them. You can help them to meet your expectations by introducing a standard code review checklist.

[Live Talk] Become a Code Review Master

Would you like to hear an expert dive deeper into code reviews? Join Codacy CEO Jaime Jorge in an exclusive talk with Curtis Einsmann, creator of the Master the Code Review course. Let's have an open talk and share our questions.

Join us in our Talk Become a Code Review Master. See you there!

👉 When: September 20th, 2022, 4 pm UTC / 11 am CDT
👉 Where: online – registration needed

Save me a seat

<!-- /wp:button -->