As Wikipedia suggests, Code Reviews are intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.
- To Share Knowledge – In a lot of development groups, each person has a core component that they’re responsible for, and each person is very focused on their own component. As long as their coworkers components don’t break their code, they don’t look at it. The effect of this is that for each component, only one person has any familiarity with the code. Code reviews helps other developers get familiar with the other components of the code which they would not have looked at otherwise.
- To Ensure Quality – There are lot of cases where developers go and reinvent the wheel. Sometimes there are flaws in the design which can lead to security or performance vulnerabilities. But reviews are not just about finding bugs and vulnerabilities. Code Reviews forces developers to write readable code, it also reduces code complexity making it easier to change the code in future.
- Code reviews can be incredibly useful but intimidating as well and therefore Code Review should never be done without published code standards. If you conduct code reviews and you have no published standards, then a review can feel like an interrogation. Developers can learn from their mistakes but only if they know what their issues are. And if developers are afraid of the review process, the positive results disappear.
- Over The Shoulder – The simplest way to do review is Over The Shoulder. This method is really useful when the code change is not very big (under 200 lines?) and usually lasts short amount of time (about 20 minutes?). Even if paired programming works for you, it never hurts to get another set of eyes on the code
- Code Review Tools – There are lots of great tools like Atlassian Crusible, CodeCollaborator, Review Board, etc. which assist with reviews. The main benefit of using Code Review Tools is that it can be done whenever the reviewer has has comfortable time that doesn’t break their concentration.
- Review by Team – Get the programmers together every fortnight and look at what has been committed. Put the code on a projector, discuss the code and talk about the mistakes. The best part about this process is that everyone knows what is being committed and every programmer improves their coding skills.
I firmly believe that Code Reviews are an effective way of spotting potential problems early in your code and it also helps rookie programmers to improve their skills. But remember to use tools for the right job, Code Reviews are not meant to check for static code or code standards. There are already tools like CheckStyle, FindBugs, JTest, etc for those purposes.
I would be really happy to hear some feedback on how you do code reviews at your workplace? And how useful they are? Thanks.