I have recently expressed my aversion to code review platforms. Assuming I managed to convince you, the next valid discussion point would be: if we’re not using a tool, how can we ensure the code reviews are effective and efficient? We could spend all night discussing the details of various approaches. While they always need to be aligned to a particular team and project, here is a shortlist of the main guidelines that proved to be beneficial in multiple projects for my teams.
Do it together. I’m a strong supporter of performing your code reviews in pairs. I believe you can get the most value with the least effort when both developers (code author and the reviewer) are looking at the same screen, talking to each other: asking questions, explaining, advising. The pairs should not be fixed, otherwise you will limit knowledge sharing and increase the risk of conflicts in the team.
Do it early. ‘Early’ meaning: as soon as your current task is coded, or even during its implementation (if it’s complex). The earlier you get a second opinion, the easier it is to change the code. While it might sound ‘unfair’ to ask an ‘innocent’ person to drop their work and review your code, my experience is that it actually improves the flow within the team. Try it and see for yourself.
Do it often. Daily code reviews can be very helpful in case of fast-moving teams that are building new systems. For maintenance-oriented teams you can adjust the period to fit the need. My preference is to keep the sessions under half an hour, so if they tend to overrun often, it may be a sign that they are not performed frequently enough.
How can we ensure that code reviews are not missed in this approach?
Make them a part of your Definition of Done. If it’s enforced properly, developers will have to perform them before moving on to another task (the concept of Kanban WIP limits can be helpful here). A development task without a code review should never really be considered ‘Done’, as some reviews can result in significant changes to their implementation.
What if all code reviews are performed by the manager/ lead in our team?
If you’re that manager – stop it. You won’t keep up with doing it properly, and you’re taking other benefits off your team members. Coach your developers in reviewing each other’s code and offer your help whenever needed. Leading an inexperienced team can be more challenging of course and requires exploring additional techniques, but avoid putting yourself as the only reviewer – your goal should be to have a self-driven team, and that’s an important part of it.
What to do in case of distributed teams?
That’s simple nowadays – use a phone and screen sharing (yes, both audio and visuals – that’s very important). If your team is distributed, you should already have this figured out anyway. As with many other practices, avoid separate locations to be an excuse for limiting communication within the team. It’s not the same as with face to face reviews, but try getting as close to that as you can.
But we’re already doing pair programming…
In that case you should already be getting most of the benefits described here – assuming you’re applying the practice properly (I may write about it one day, too). I would still recommend to occasionally bring in a 3rd developer to have a fresh look at the critical pieces of the code, but in general your team is in a much better situation already.
At the end of the day, it’s important that you promote a culture of close collaboration and open discussion in the team, and the way code reviews are performed can have a significant impact on this matter. If people avoid discussing with each other and hide behind a tool, that’s going to cause more and more problems in the long-term. Instead, follow a light but strict approach of frequent, short reviews performed in pairs, giving an early and direct feedback about the code changes.
Please feel free to describe your approach to code reviews in the comments.