Improving Performance in Code Reviews

Tips and strategies for optimizing performance in pull requests

Pull requests are an essential part of the software development process, allowing teams to review and discuss code changes before merging them into the main codebase. However, as projects grow larger and more complex, pull requests can sometimes become slow and inefficient. In this article, we will explore some tips and strategies for improving performance in pull requests.

Common challenges

Some of the common issues seen on different organizations are:

• Pull Requests are not as effective as people may like. Sometimes there are bugs that should be caught at the time of the review but they go all along QA or even worse till the product review, causing delays on the pipeline.
• Pull requests are sitting for several days and it is hard sometimes to get people looking at them
• Code quality is not as good as people expect, and later there is an importat tech debt that has to be addressed.

Strategies for Improving Performance

There are several strategies that can be followed in order to minimize the challenges seen above:

1. Set up the culture: One of the most important things that is often overseen is to set the team culture. This means that everyone involved should understand the importance of this process, and understanding that, even though people tent to visualize them as individual contributors, the team succeeds of fails as a whole. Having half made features at the end of the sprint is not useful at all. Finishing your work, but not helping others is a problem that have to be tackled. Also something that has to be avoided is the QA vs Development mentality. Defining QA dropsand making sure that they have enough time to test things will improve the chances to meet all the sprint commitments in the best way possible. And making sure that the Pull Requests are not sitting idle for days is a great way to start tackling what ends up being a big bottleneck.

2. Optimize code review process: Streamline the code review process by setting clear guidelines and expectations for reviewers. This can help reduce the time spent on reviews and improve overall efficiency. The team can create a template that can be automatically attached to each Pull Request in Github/GitLab in order to remind the reviewer what are some of the common key points that have to be checked.

Some check examples can be:

• Check code complexity, for instance checking big O notation.
• Code simplicty is important, make sure that the code is readable, has comments where needed, good variable names.
• Check coverage: having unit tests that are meaningful is important to minimize later bugs introduced by a team members because of lack of knowledge on a particular feature (in here can be frontier test cases and happy path if applicable).
• If you have translations, make sure that everything has it's own key, and there's no hardcoded text.

3. Reduce pull request size: Break down large pull requests into smaller, more manageable chunks. This can make the review process faster and easier for both reviewers and contributors. If the PR is 50+ files to check, chances of having an effective code review can potentially decrease.

4. Use performance profiling tools: Utilize performance profiling tools to identify bottlenecks and areas for improvement in the codebase. This can help pinpoint specific areas that need attention and optimization. Code Climate is a good system example to check code quality and unit testing, that can be added as a git hook.

5. Implement automated testing: Integrate automated testing into the pull request workflow to catch potential performance issues early on. This can help prevent regressions and ensure that code changes meet performance requirements. In here, Sonar Cloud is another good example.

6. Make the pull requests as efficient as possible: It is important to make the best use of the time of everyone who's involved in the process. Something that has proven to be helpful is to set a quick meeting for the involved people to get some context over the code and also see it working. That way, the developer can get realtime comments and start fixing different things if needed without needing to wait for the full process to be completed. Also this will help for everyone to check that the basic acceptance criteria is being met. After that process, the reviewer(s) can check on their time and do some offline comments if required and accept, ask for changes.

7. Make the time: One of the biggest issues I've seen with reviews, is that people are often way too busy to spend the appropriate amount of time, and then making the time at the end of the sprint, with less time. This often hurts deliverables and also the QA team, which will have less time to achieve the goals. Blocking some time for the team is a strategy that has been helpful over the time, let's say starting with 1 hour per day, that can be spread on 2 blocks of 30 minutes. At the beginning or middle and end of the day for example. It there is code to be reviewed then the time can be honored, if there is nothing to be checked, then this block can be avoided.

8. Make it visible: Having tools like Jira, Pivotal Tracker, etc. is great to check on the tickets and assign things to people. But sometimes this is not enough. Developers are not paying attention to every single notification on realtime or checking their email every 10 minutes (and this is totally normal and good for the efficiency sake). Having team chats (with developers and perhaps QA depending on your process) is a great way to have realtime communication and make sure that eveyrone is on the same page on what features are ready to be checked and can be prioritized based on QA drops, risk, etc.

9. Create merge requiements: Last, but not least, having merge requirements is important to avoid the "Looks Good" comment from team members that oversee the whole code. In my experience, some of the things that have worked are:

• Having at least 2 reviewers to check and accept the code, adding a small comment on findings.
• Having automated hooks that run code quality gate.
• Having automated hooks that runs the unit test suite. For the last two, code climate and sonar cloud are easy to configure and add as part of the Software Development Life Cycle.

Conclusion

Improving performance in pull requests is crucial for maintaining a smooth and efficient software development process. By optimizing the code review process, reducing pull request size, utilizing performance profiling tools, and implementing automated testing, teams can enhance the overall performance of their pull requests. As engineers continue to seek solutions to pull request performance issues, it is essential to stay proactive and explore new strategies to ensure smooth collaboration and code integration.