What is a code review?
Definition
According to Wikipedia, a code review is:
A software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code’s author.
And in simple words, it means that to improve the quality of this company’s product, it is necessary for different people to evaluate the code. There are still a lot of ambiguities:
- How should a code review start?
- How do you tell if a code review is good or bad?
- How long should a code review be?
Preparation Is Key
Before you go into the code review itself, ask these two questions:
- Are you aware of what your co-worker has been working on?
- Are you familiar with the area of the code they have been working on?
If you answered no to either of these questions, then you need to do some homework. This is so you can come to the code review as prepared as you can be.
One way of bridging the gap is by looking at the ticket/issue associated with the feature. There you should find enough information to let you know the scope and reasoning behind the developer’s task. Furthermore, if it is customary in your workplace, you can look over the comments on the ticket. You want to see if there have been any changes to the ticket that do not match the original intention. And if all else fails, before you begin the code review, ask your team member to explain what they have been working on and why.
Be empathetic but honest
Developers take pride in their work. Like most human beings, they do not like to hear someone else tell them what they are doing wrong. Be that as it may, it is important to let your voice be heard as the reviewer.
Similar to how each person will have a different flavour of ice cream, each developer has a different opinion on how code should be written and maintained. Nevertheless, there are certain common truths each developer must adhere to. So in order to keep things calm, be sure to phrase your statements in a constructive manner. That way, no one should get offended.
Sure, you will have disagreements. In certain situations, it will be important to stress the drawbacks of the code that needs to be re-written. If you reach a dead-end, try to bring it up with another developer or a team leader. Never forget that on the other side, there is another developer with their own point of view.
Good Things To Keep In Mind
While the subjects discussed above form the tripod of a code review (if you will), there are also other things to pay attention to:
- If relevant, ask if unit tests have been added and if so, go over them
- Documentation is part of the code review (and if there is none, discuss the point of adding it)
- Before the code review starts, ask the developer how long they think it should take (this will help you plan your day accordingly)
- If there are many changes following the code review, make sure to schedule another one so the next iteration doesn’t go unnoticed
- Be courteous and try to give the other developer compliments on what they have done
Tips Code Review
- What to Look for in a Code Review
It’s important to go into reviews knowing what to look for in a code review. Look for key things, such as…
Structure. Style. Logic. Performance. Test coverage. Design. Readability (and maintainability). Functionality.
You can do automated checks (e.g., static analysis) for some of the things — e.g., structure and logic. But others — e.g., design and functionality — require a human reviewer to evaluate.
Reviewing code with certain questions in mind can help you focus on the right things. For instance, you might evaluate code to answer:
- Do I understand what the code does?
- Does the code function as I expect it to?
- Does this code fulfil regulatory requirements?
By evaluating code critically — with questions in mind — you’ll make sure you check for the right things. And you’ll reduce time when it comes to testing.
- Don’t Review Code For Longer Than 60 Minutes
Never review for longer than 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point. It’s best to conduct code reviews often (and in short sessions).
Taking a break will give your brain a chance to reset. So, you can review it again with fresh eyes.
Giving yourself time to do short, frequent reviews will help you improve the quality of the codebase.
- Check No More Than 400 Lines at a Time
If you try to review too many lines of code at once, you’re less likely to find defects. Try to keep each code review session to 400 lines or less. Setting a line-of-code (LOC) limit is important for the same reasons as setting a time limit. It ensures you are at your best when reviewing the code.
Focusing on fewer than 400 lines makes your reviews more effective. And it helps you ensure higher quality in the codebase.
- Include Everyone in the Code Review Process
No matter how senior the programmer is, everyone needs to review and be reviewed. After all, everyone performs better when they know someone else will be looking at their work.
When you’re running reviews, it’s best to include both another engineer and the software architect. They’ll spot different issues in the code, in relation to both the broader codebase and the overall design of the product.
Including everyone in the review process improves collaboration and relationships between programmers.
Conclusion
Learning how to effectively code review is important for your success as an individual as well as a team. Do not use this time to show how smart you are but use it as a collaborative session. Code reviews are a great opportunity to provide bi-directional coaching and mentoring.
