The 5 Key Steps to Review Prior to Submitting a Pull Request

I have been submitting and reviewing pull requests for the last 6 years and I can confirm there are some basic things that should be covered. By doing these basic things you will help your fellow colleagues and make their life much easier when reviewing your pull requests and consequently improve your team's velocity and efficiency.

Working in a team that is functioning well can lead to incredible results and pull requests are an integral part of any software team. The team should make sure that their pull requests are running smoothly otherwise it can create tension and conflicts within the team. To that end, I have listed the top 5 things you can check on your pull request before submitting for review to help them flow through like a lubed up fish.

Top 5 things to check in your Pull Requests

1. Code correctness and quality: Ensure that the code is correct, efficient, and follows good coding practices. Run all tests associated with your change to make sure your code does not break any existing functionality. If your code in the pull request doesn't fulfil the functionality it is trying to achieve then it shouldn't be a pull request in the first place.
2. Code readability and style: Check that the code follows established style guidelines, is well-commented, and easy to understand. If your team doesn't have style guidelines then make some!! When many developers are submitting code to the same code base it's critical that all developers are working along the same guidelines. And there are plenty of tools to help you in this! You should use a linter, formatter or style guide (e.g., PEP8 for Python, ESLint for JavaScript) that the project follows to validate your code. Prettier, although opinionated, really helps Javascript code format consistently across a codebase.
3. Update documentation: Update any documentation related to the code – including README, Wiki, comments, or user manuals – if necessary. Documentation is integral to the success of any application so keeping it up to date and helpful is very important. By making changes to the documentation regularly, you are much more likely to succeed in this area.
4. Merge conflict resolution: Before submitting a Pull Request, make sure your branch is up-to-date with the target branch, i.e., there are no conflicts between the two branches. You should merge or rebase the target branch into your working branch and resolve any conflicts if necessary. There is nothing more annoying than reviewing a pull request that will undergo further changes once merge conflicts are resolved.
5. Properly structured and complete request: Ensure your Pull Request is well-structured, including a clear summary of the changes, the purpose behind them, and any potential impact on the system. The request should be easy for the reviewer to understand and provide all necessary context, such as attaching relevant issue/task IDs, providing test cases, and mentioning any assumptions or limitations. REMEMBER: You colleagues are busy and involved in their own stuff. Anything you can do to assist them in reviewing your code will really help get things merged quicker and to a higher degree of accuracy.

Conclusion

Pull requests don't have to be complicated. Maybe some of the code changes will be but the process itself should aid a team and not hinder it. Take the responsibility to make sure your pull requests are at least doing the basic things right. If you see someone on your team consistently overlooking something on their pull requests then guide them and help them improve. By focusing on this process you can really help your team grow and work really well together and hopefully produce successful applications.