In every software development life cycle, the code review remains one of the key steps in delivering a successful and qualitative product.
In most of the cases, the code review is a ‘Make It Or Break It‘ moment.
Often neglected, regularly underestimated, the code review is sometimes skipped for deceptive reasons.
Today, we are going to enumerate the 6 best tips in order to perform a successful and fruitful code-review.
I – Choose The Right Moment
Performing a successful code-review begins by choosing the right moment to perform it.
What is the right moment to perform a code-review?
A good moment holds the following characteristics :
- Low probability of being interrupted : you should tend to avoid times of the day where you know, by experience, that people tend to interrupt your work. Days often have calmer periods and this is where you should hold your code review.
- Right state of mind : you weren’t stressed ten minutes before, or dreading an important meeting one hour after. Both the reviewee and the reviewer have to be in a good state of mind to guarantee that no turbulences will ruin the code review.
- The reviewee ensures that the code is review-ready : there is really no point in wasting time reviewing a code that is not ready. By ready, it is implicitly meant that the code should be qualitative, commented and unit-tested at least. If the reviewer allocates time to review some code, it is really nothing at all to come with your paper ready.
II – Set The Boundaries Of The Code Review
Before starting the code review, you have to set correct and attainable boundaries for it. That means that you have to know exactly what you are going to cover, ahead of time.
Are we going to review one or multiple features? Given the time we allocated in the step before, does it make sense to review too many features?
A code review can consist in integrating multiple small features or a few big ones.
In many cases, you want to be focused on a few features in order to grasp exactly what they are about and not jumping too frequently from one feature to another.
In order to set boundaries, you may want to :
- Have well-written and correctly sized tasks in a ticket management system like Jira or even a classic white-board for example.
- Correctly prioritize the code review : some tasks may be more urgent than others. If too many tasks need to be integrated, you cannot perform all of them. Choose wisely.
III – Set The Right Environment For It
This point is a very important one.
Before starting any code review, you want to set the correct environment for your code review.
What are the characteristics of a proper environment?
- Your environment has to be quiet : code reviews cannot be performed efficiently when there is a lot of noise around you. A good focus is essential to be efficient in the task you have to accomplish.
- No interruption-zone : similarly to the point we described in the first part, you may want to be in a room with restricted access, underlying the fact that you don’t want to be disturbed during the process.
- A positive cristicism zone : criticize somebody’s work is a hard process. But it is even hard when a lot of people are around you. In a restricted room, you are free to express your comments without fearing that somebody’s going to listen to it.
IV – Communicate, communicate, communicate
I really wanted to put some emphasis on this point.
A code review is not a one-way process, quite the opposite.
A successful code review relies heavily on being able to respectfully and efficiently communicate with your peer.
A code review isn’t only about the reviewee expressing its intent. Neither is it only about the reviewer stating what’s right and what’s wrong.
It should really be a conversation about everything that composes it : the scope, the intent, the fixes and even the disagreements.
Here are the keys points for a successful communication :
- Don’t just hear, listen : the code review has to be a understanding and insightful moment. You can not listen to the sound of your own voice. Opinions and views may differ and every disagreement should lead to a constructive discussion about what the issue is.
- A neutral tone : a code review isn’t a whiteboard exam, nor an inquisition. It should feel like the code is being judged, not the developer behind it.
- When in doubt, ask : if you’re not sure about a particular detail in the code review, ask about it. Some intent isn’t made clear from the beginning and could lead to misinterpretations.
V – Keep In Mind The Deliverables
A code review always lead to a deliverable : it can be a counter-review of the code presented or a code integration to the relevant branches that you chose for your gitflow.
This is where the responsibility of the reviewer is involved. The reviewee is responsible for presenting good code to the reviewer but the final decision belongs to the reviewer.
How does one judges if the code can be integrated or not?
Here are some criteria that can help you in your decision :
- The code written and the development done is relevant to what was asked in the ticket dedicated.
- The code is correctly unit-tested and is ‘considered safe’ to master branches.
- No obvious code smells or bad practices.
VI – Use Dedicated Tools
Tools to perform a proper code review exist and you shouldn’t hesitate to use them to ease your integration process.
Such tools often provide a complete interface to organize code-reviews, as well as metrics in order for your team to continuously improve.
It is way more than a code comparison tool, and it integrates with pretty much all the source version control systemsavailable.
Give it a try!
Did those tips help you organize your code reviews?
Does your role in a code review make more sense now?
If you have additional tips to share, or concrete examples that happened to you in your daily developer life, make sure to share them by leaving a comment below.
It really helps new developers.
Until then, have fun, as always.