How to Prepare for Code Reviews
Here are some actions you can do on your own to ensure a successful code review session.
Are you new to code reviews? Always feel like you mess them up in one way or another? Today I have some essential tips for you to prepare for code reviews properly.
The correct way to prepare for code reviews is to make sure you can review your code first, eliminate any mistakes you made along the way, test that the code is doing its intended function, and make sure it upholds your team’s code standards. Let’s dive into these more in-depth.
Review Your Own Code First
Most development teams use git tools like GitHub, GitLab, or some other git repository to review your code with or without you.
So, if you use GitHub, your process may look like this:
Write code.
Test code.
Open PR and assign reviewer.
According to the review answer, merge or fix.
From now on, you’ll add a slight change and add a Draft PR. This means you already open the PR but as a Draft. In other tools, that might mean you have to prefix the name of the PR with “WIP:” or something similar.
Just don’t add your reviewer yet.
Creating such a draft PR will allow you to be your own reviewer first. You will have all of your code in plain sight and can see what you pushed on your branch. Maybe there is some code you added for development purposes? Now is the time to get rid of them.
Test Your Code Before Sending It To Review
You’ll be amazed how often a small change can cause an entire service to malfunction. You don’t want to send for a review when your code is causing the service to crash on startup. And believe me, that happened to me multiple times while developing microservices in the past.
Do yourself and your reviewer a favor and test that your code works. Don’t have CI/CD at work that automatically builds your code (for example, docker images)? That’s on your DevOps more than it is on you. You’ll have to do it the hard way by building a docker image, but I still urge you to do it.
Now, testing that your code is doing its intended purpose is only part of the testing you should do. What about testing that it doesn’t break when using it differently?
Uphold Coding Standards
Your team might use GitHub Actions to enforce some coding standards on your code, like Linting, Typing, and Testing.
If that is true and when you open the Draft PR, you see some X’s appear as part of some automated processes that your PR triggers, you should eliminate those issues before making your PR ready for review.
That means going over your linting process and fixing linting across the files you changed (running a linting command and using a tool like pre-commit can make sure you only push linted code).
And if you should also fix typing mistakes, you will need to test your code again. Typing fixes can trigger unwanted results if you don’t do them right. And a tool like Mypy can help discover those errors.
Conclusion
You can do a lot of work on your own before sending your code for review. You only need to spend the time to make sure your reviewer can focus on the thing that matters: your code.
If you do your PRs correctly, you’ll usually receive minor notes and approval. If there is some major conflict in how you and your reviewer see the solution, at least that discussion can be about the difference in your solutions instead of trying to defend low-quality code that needs fixing. By doing your preparation work beforehand, you will also be more confident in how you present your code to anyone who will review it.
How do you prepare for code reviews? Let’s discuss your experiences in the comments.