How to perform a code review
Regular code review during the course of a software project helps to complete the project smoothly. Unrepaired bugs are like a snowball. Detecting them at the very end of the process costs significantly more effort, time, and money which is spent on last-minute fixes. How to conduct code review in order to avoid the accumulation of errors and maintain a good atmosphere in the team?
My suggestion is to look at code review as two layers of work. The first layer is purely technical. Planning and organization help to reduce errors. The second tier is the social and emotional aspect. It's worthwhile for you to rethink communication, taking into account aspects of the personalities on the team and how they work. Communicate to your team the most important points about code review and the approach to its organization. Well, yes, but what to communicate to them and how to organize it?
Code Review in technical terms
Before you start code review, put its various elements on the process path. Permanently. Regular code reviews are the only way to avoid last-minute project fixes. Only when the space for code review is blocked on the process map, move on to planning its specifics.
First, determine what areas the code review will cover. This way, everyone will know what to expect and what elements are critical to projects.
Knowing exactly the space you'll be covering, set a strategy for how you'll operate and test. A common mistake during code review is duplicating work that can be done by automations. If something can be tested by automation, there is no point in putting time and effort into it. So how to do code review?
Code from a holistic point of view
Focusing only on new code is a mistake that happens in every team. Sometimes it's tempting to check only the new code elements and status since the last code review. Treat the code as a whole. Check:
- what impact the new code has on the old part,
- if the logic of the code has not been disturbed by newly written parts,
- if there are no fragments left relating to the deleted code, such as old queries.
Checking the new code is not only to determine the correctness of its writing. Before you start the first code review determine, what function the new code plays in the whole system, and do not disturb its structure. Speaking of structure, I mean both the logical correctness, as well as the appearance of the code.
Why do you need regular code review?
The rule is simple: unchecked code does not pass further, and it blocks the implementation of subsequent tasks. Regular code reviews mean smooth work for the whole team.
When reviews are done too infrequently, more problems arise. Limited time for code review doesn't allow you to write good comments, and without them future reviews, fixes, and changes become more difficult.
Of course you can divide code review into smaller stages, which also works, but in this case regularity is the key to success.
Code review from a social perspective
Code review (CR) is not just checking technical aspects of a project. It's working with a team made up of people. Nobody likes to be shown the mistakes they made while writing the code on the forum.
That is why it is a good idea for you to establish a kind of CR work culture with your team. You also need an ironclad consistency in keeping your agreements. A cool head will always be in place. Do not let emotions in the team take over.
Above all, build awareness in the team that code review is not a personal picking on people from the team, code review is:
- caring about the quality of code;
- developing skills of both the reviewer and the reviewed;
- space for creating new ideas and out-of-the-box solutions to problems.
Commonly encountered problems during CR are stylistic errors. How to treat them? It's simple. Differences in code writing style are natural and occur in every team. Discussing them is actually working on best practices and a consistent flow. By approaching code styling in this way, you will build a sense of good organization within the project.
Remember: the only enemy during code review is bugs, not team members.
You don't know everything, that's a fact.
A development team is a compilation of people with different experiences, knowledge, skills, and interests. Often by checking out the code, you can learn a lot from others. A developmental approach to CR is a simple path to becoming better.
When you are thrown by a piece of code that you yourself would simply write differently, ask yourself if that's really the problem. Imposing your "better" solutions is not always an effective way to achieve a goal. Discuss the issue with your team and suggest another solution if necessary.
It may happen that some of the code is not fully understood by you. The worst thing you can do when you find a bug or such a piece of code is to leave a "wrong" comment. Play the role of a mentor, describe the problem and explain why your solution will work better.
Be like a good father "Strict but fair".
There is no allowance for bugs in code, point them out as well as describe, explain, and talk them through with your team. Remember that by checking the code, you actually take responsibility for it. That's why you can't afford to leave defects in it.
Direct your strictness towards bugs, not people. The worst thing you can do during a code review is to take personal jabs or insult the person responsible for a given piece of code. However, sometimes it may happen that you will disagree whether the pointed out bug is really a bug. Then look for a third person to solve the issue.
Approach each code review individually. Try to understand why the person wrote the code in such a way. Perhaps it is a junior for whom code checking is still a very stressful part of the job. Often the problem may lie much deeper than in Git, and arranging a call and explaining the whole thing is the best way out.
How to build a good atmosphere around CR?
There is one irreplaceable method to build a positive code review experience. It's praise. If you see code that you like, praise its author. Everyone likes to be praised, even a Senior, from whom high quality code is expected, will be happy when you point out a job well done.