Code reviews are an invaluable practice that many software development teams often over look. This article explains how to put them in practice. The hope is, by establishing the key elements of code reviews, developers can more confidently work code reviews into their software development process and team environments.
Why do we do code reviews?
Code reviews have a number of benefits. A small list of the benefits include:
- A different or new perspective can spot potential issues that the original developer may not have seen.
- Reviewers bring experience from past projects and can identify common pitfalls that they have had to work through.
- Learning can go two ways: Both reviewees and reviewers have potential for learning patterns from each other.
- Socialization of how new software is written. This allows us to gain insight into what projects have solved what problems, and having the ability to reference that code for use in future projects.
- Knowing that your code will be reviewed can lead to better programming practices.
What does a code review entail?
Ideally, code reviews are no more than a dialog between two or more developers about a finite amount of newly written code. (“Just talking ’bout some code bro.”) The amount of code should be small enough so that the code review can be done relatively quickly and encapsulates a related set of features.
The developer who wrote the code should provide reviewer(s) with relevant background information about the problem that needed to be solved and then proudly speak to and show the code that was written. The crucial keyword at this step is proudly. Before getting to the point of code review, developers should ensure that the code they are writing lives up to their team’s code quality standards and they are also satisfied with the pattern of implementation. If they are not able to come to satisfactory pattern for implementation, reaching out to team members for help is always a good choice. Better to ask for another eye on a problem early than to waste time and brain cells on something that ultimately will need to be refactored.
Once the code has been spoken to, it is the reviewers job to ask questions. Coming up with and asking questions is the key to to successful code reviews as it challenges both the original developer and the reviewer to look at the problem being solved and the code in a new light.
In addition to asking good questions about the code, there are a few other questions reviewers should be asking themselves:
- Is the code easy understand? Should it be refactored or are comments needed?
- Are there any areas that can be optimized?
- Is there repetitive code that can be broken out into a re-usable method?
- Are coding standards being followed?
- What can I learn from this?
When should we do code reviews?
Just like voting in Illinois, code reviews should be done early and often. A good rule of thumb is any time you are creating new code that is adding a feature or solving a problem in existing software, you should ask for a code review. In addition, it can also be useful from time to time to ask for a code review on common programming tasks.
Who should do code reviews?
Everyone. Literally every developer regardless of levels of experience should ask for code reviews.
Code reviews are NOT a judgement on the code being reviewed
Finally and perhaps often overlooked, the intent of code reviews is NOT to cast judgement on the work product that your peer developer has worked so hard on. Plain and simple, don’t be a jerk and also don’t be afraid about your work being judged.