When it comes to reviewing code, there’s a right way to do it…that we sometimes don’t follow. However, taking the time to be concise and properly review the code itself will help you ensure that you are protecting the integrity of the project’s code while respecting the time and input of your fellow collaborators.
Here are a few best practices to follow to help you be the best code reviewer possible.
Be Timely
It’s a good idea to review code ASAP – likely within an hour or two of submission. If a review is done quickly, the case can be closed and your collaborator can start working on something else. If you drag your feet, they may start working on something else, and then have to return to make changes, which derails their flow from the task they started while waiting for a review. Remember that context switches can be time-consuming, and getting those reviews done fast will help keep the workflow moving smoothly.
Don’t Make the Code Reviews About You (or Your Opinions)
Disagreements happen, however, if your team can develop a culture of going with the best argument, you are much more likely to be able to take your ego out of the equation. Remember: your way isn’t necessarily the best or right way. If you think you’re right, make sure you can back up your defense with proof via documents or links. The best reviewers keep communication lines open and allow space for their minds to be changed.
Get Third-Party Input
It’s always a good idea to get another person to review your review if you have reservations or are on the fence. Gathering input and talking through your side of the review may help provide the clarity needed to properly suggest an updated change or to accept or reject the pull request.
Make Sure Your Feedback is Constructive
To err is to be human, however, rejecting items or suggesting changes without context can be a hard pill to swallow. Be careful with your language when offering suggestions for corrections. Don’t just say “No, do this”. Try, instead, to say “I would suggest X”. Remember that your review is more of an opinion than a directive and that written opinions can be taken out of context if worded poorly.
Don’t Treat Temporary Code Differently
There may be times when code is submitted as a temporary fix and may have a commit message such s “hotfix”. However, just because it’s “temporary” doesn’t mean the code should be treated any differently. Sometimes these short-term solutions end up being more long-term than you might anticipate, and, if not reviewed just as thoroughly, can quickly snowball into bigger problems down the line.
Be Clear, Concise, and Precise
When writing comments, be careful about how you are constructing the review. Double-check every comment and avoid grammatical errors. Be clear about what, exactly, needs changing and which exact line you are referring to in order to avoid unnecessary back and forth about the “meaning” of the review comments.
Check The Work!
While, in a perfect world, the author of the code will have already tested the submitted code itself, never assume this. Always make the effort to try the code out for yourself. Don’t just run simple tests, either. Challenge the underlying code by trying to cause errors and see if there are edge cases that need to be addressed.
Conclusion: Remember to Think Bigger Than the Line of Code Itself
While reviewing code often requires careful line-by-line inspection, reviewers need to remember that they need to consider not each individual line, but how the line integrate with (or benefit) the application or project as a whole. As yourself: will this change benefit the project? Is it a scalable solution? Will anyone be able to read the code weeks or months from now? Pull requests are building blocks that make up a larger, more extensive product, so, no matter what the pull request, keep the bigger picture top of mind before approving or rejecting during a review.
Do want to integrate your Git and Jira applications together to make project management even easier? We have an app for that. Try our apps for GitHub, Git, GitLab, Bitbucket, Gitea, and Beanstalk – all of which allow for easy integration with Jira!
