As a dev just a year out of college, it is easy to tell myself I’m not qualified to review a senior dev’s pull request (PR). Reviewing pull requests, however, is a great way for a new dev to learn best practices and the codebase. After discussing this feeling with my manager, Joe Chrysler, he encouraged me to tackle this feeling head-on and get to the bottom of it. With his help, I realized I needed a process for reviewing a pull request that allowed me to feel confident giving it my stamp of approval. Ultimately, this took the form of a checklist run-through for every PR I review.
1. Does the code address the story description?
Read through the story that the code is addressing. Great! Now do it again. Make sure you fully understand the requirements of the feature so you can tell whether the code solves the right problem. It’s easy to miss details when you’re in a rush. Checking the feature outline before you start reviewing is a great way to combat this.
2. Does the code run locally?
Pull the code and run it locally. Test the feature requirements on your machine so you feel confident it’s solving the problem. Sometimes it is easy to look through a smaller PR and approve it without doing this step because it seems like a hassle. However, this is an essential step in PR reviewing. It’s never fun when you merge something to dev and are surprised to see it’s not working.
3. Is the code properly tested?
If new code was introduced into the system as part of the PR, is it being tested? If a developer modified old code, are the tests still testing the right thing? When the developer removes code, were the tests removed as well? These are all great questions. They make sure that the code is manually tested and tested automatically as well. For me, this was a great step in boosting my confidence when approving pull requests. Knowing that I can rely on not only my manual tests but also some automated ones helps me trust that the code is solid and ready to go.
4. Is the code developer-friendly?
This is probably the most challenging part of code review. Now that you’ve gone through the previous steps, it’s easy to think you’re done and the PR is ready, but that’s not quite true. Another essential step in code review is asking yourself if the code reads easily and makes sense to someone who didn’t work on it in excruciating detail. If the code feels complex and hard to read or understand, there’s a good chance it needs more work. If another developer on the team can’t jump into the new code and easily understand it, that will be a big problem in the future. Take time on this step to make sure there aren’t simpler ways of solving the problem or opportunities to reorganize code (moving finer details out into helper functions for example). And be sure to check if variables and functions have good names.
You can review pull requests with confidence.
These are the four steps I take now when reviewing pull requests, and it has helped me immensely in feeling confident when I hit that approve button!