Recently, I came across a situation which once again proved the immense value in having code reviews. I was working on a tricky part of an application that involved substantial design work. As part of our 'Definition of Done', I had to submit my code for a peer review. The review turned out to be invaluable - after all, it's always useful to get the second pair of eyes to look at your work.
At the same time, the process of a code review has less than a stellar reputation. Often, it is perceived as a burden for the people who have to do it: developers assume that it is not directly beneficial for them, since it may only unearth minor coding style issues.
First of all, a code review does not have to be done by one person or a committee of senior developers. On the contrary, every developer can have a chance to review their colleagues' code. In this case, it is called a peer code review. Such a review not only improves code quality, but also facilitates robust knowledge sharing. Furthermore, it works both ways: not only can a reviewer suggest better practices for solving challenging problems, but also the reviewer themselves can learn a lot from reading somebody else's code.
For example, say that there's a new starter in your team - someone who could bring lots of good ideas on board. A code review is the perfect place to introduce such ideas, whether that person is reviewing somebody else's code, or their code is being reviewed. Furthermore, a code review is not just about sharing best programming practices - it also helps developers to become familiar with the entire code base. As a result, it becomes easier for them to start working on the components they have not worked on before.
In addition to getting your workmates to review your code, it's also crucial to do so in a timely manner. After all, if code reviews only take place once every few months, it will become very difficult to respond to the issues arising from them. In other words, if a code review discovers technical debt which has been accumulated in the last two months or more; it might take a considerable amount of time to clear the debt.
Conducting code reviews frequently can mitigate the rate of increase of technical debt, and make it possible to quickly address any discovered issues.
This raises the question: how often should you have a code review? One of the answers to this is not to base your code review frequency on any specific time frame, but instead to tie it in to your development life cycle. At NCR CoDE, no story can be considered to be done until it passes a code review.
There several ways of conducting a code review. Developers can just sit next to each other and go through the code. Personally though, I prefer when the code I've written is reviewed without my involvement. Otherwise, I could convince a reviewer that my not-so-good design decisions are actually fine. Moreover, this approach does not force a reviewee and a reviewer to be at work in the same place and at the same time. Hence, it scales across different geographical regions and time zones.
While the code review process is agnostic of the development tools in use, there are still applications that can help you to accelerate the process. If your team is using Git and is working with feature branches, then this workflow already enables your developers to perform code reviews via merge/pull requests. A developer completing a story submits a merge/pull request, that is picked by another developer. This guarantees that only reviewed code lands on the 'master' branch.
Code reviews can be extremely beneficial for your development team - if they are done right. Every developer must be given a chance to give feedback their colleagues' code - both parties will benefit from it. It is equally important to have regular code reviews.
The best way to accomplish this is to integrate them into your development life cycle. A code review can be conducted across country borders and time zones. Finally, there are tools that can help to bring code reviews to your team.