Today I would like to talk with you about code reviews. Actually, I would like to share a few tips which should help you as a reviewer and make those reviews really helpful for people who request them. Ok, let’s start.

• First and foremost, don’t do code reviews when you have a bad day. Really, when you feel this is not a good time let know the person who requested PR that you will do it later because you are busy right now, or simply too tired to correctly focus on the code. We are just humans, it’s better to postpone it than regret it. When you are stressed or angry it may really impact your review and actually cause you to be more likely to hurt someone, than provide proper and valuable feedback. Kind code reviews (even rejects) with some valuable feedback are simply more helpful as they cause the requester not to feel personally attacked. In addition to that whole point, I can say that it’s also worth not doing the code review for too long as it’s exhausting for a lot of people so even if you start it in a good mood after let’s say 2 hours you might be completely out of empathy 😉
• Now from the technical perspective, it’s really worth preparing a personal checklist, which will help you not forget about all the things you should check during code review. In the case of every type of developer, this list might be different, but after a few reviewed PR’s you will definitely find a couple of areas or topics, which should be always checked. There are some obvious topics like SOLID principles, readability, security, and tests. But for some devs, there might be less obvious things that should be considered, for example in mobile projects I always try to check if that change will correctly work if the user will not grant a demanded privilege or leave the app in the middle of the expected flow, because of a phone call or something else. Your project probably also has some platform-specific things that you are aware of.
• Another important tip in my opinion is to try to understand the whole idea of PR before you go into the details. Some solutions, which may look weird when separated, may make way more sense if you understand the whole solution. Maybe it will turn out that the requester did not have any choice, and that’s actually the best possible solution, even if it’s weird 😉
• Talking about some small weird things, this is not a strict code review tip, but nowadays you can automate a lot of things and it’s definitely worth doing! Different languages provide different tools, but in most cases, you can at least run some lint checks, which will quickly catch some easy-to-fix issues, that can be fixed even before the proper code review, this will save time for both the requester and reviewer. If your CI is able to run tests, or for example compile and check syntax then it will definitely make everyone even happier 🙂
• Btw. try to not focus only on the code, think about the big picture, how urgent is the change done in this pull request, whether is it only a hotfix, or a big change that may impact the whole codebase, what about time to release, do you still have time to eventually optimize it, or should you deliver asap? Different situations demand a different approach, programming demands about being flexible sometimes 😉
• The next important thing to keep in mind is to remember that code review’s most important goal is to make sure the solution is correct, but PR should be also a source of knowledge for the requester. Unless it’s just a one-liner or a simple hotfix, try to think about possible improvements and solutions, which quickly come to your mind and mention them, so next time this coder can think about them and simply write a better code. Don’t simply mark what’s wrong, put some effort to explain why and eventually how it can be improved. You will definitely devote more time to this review, but maybe you will save way more time reviewing the next PRs of this developer for the next year or more.
• Last, but not least! Don’t forget to notice good things! The goal of the review is to find imperfections in the code, but don’t limit yourself to commenting on what’s wrong. Try to appreciate good solutions and mention them in the comments, this will definitely reduce tension between you and the requester, don’t be afraid to admit that some solution is great and you didn’t think it can be done this way.

Ok, I think I’ve shared with you all my thoughts about code reviews and I really hope those tips will help you make code reviews less painful. If you have some observations which I forgot about feel free to share them in the comment section.