In this installment of my three part software engineering best practices series on code reviews (read part one here), we will look at how to make code reviews successful. Code reviews are one of the most effective software engineering best practices you can adopt to increase the quality of you organizations code. However, as with many things in life, they won’t help much if you’re not doing them correctly.
Here are four things to keep in mind about how to conduct your code reviews.
1. Code reviews need to be mandatory
If you’re serious about consistently producing quality code, then code reviews should a mandatory step in the software development lifecycle (SDLC). Before any code is checked in to source control, it needs to pass a peer review. If reviews are not a regular step in the development cycle, they won’t be taken seriously and will likely be perceived as a nuisance. Your team also won’t be very skilled at performing them because they will be uncomfortable with the process. As a result, the reviews will either be ineffective because people are rushing to get them out of the way, or they will be a bottleneck because people have to remember how to do them properly.
The other issue with non-mandatory code reviews is trying to figure out which code necessitates a review. If someone really doesn’t want to review their code, they’ll try to justify why a review isn’t necessary and a power struggle may ensue. Mandating that all code pass a review eliminates these ambiguous situations.
2. When should code reviews be done?
Code reviews need to be done promptly. You don’t have to drop everything the minute you receive code to look over, but you need to get to it in a reasonable amount of time. Within an hour or two should be acceptable in most cases. Remember, other people are waiting for your review to be complete and your review is an important contribution to the overall process.
3. What should you say in a code review?
You only need to say what’s necessary. One of the biggest problems people who are new to code reviews have is fighting the urge to always say something. If you find something to criticize in every submission, people will start to tune you out or you will erode your credibility. If the code is acceptable, there is nothing wrong with simply saying “Looks good to me,” and leaving it at that.
4. What do you judge in a code review?
You are looking for the correctness of the code, as the author wrote it. There are millions of ways to implement a programming solution and the point is not to promote your own idea of how a problem should be solved, but to judge whether chosen implementation contains bugs or otherwise falls short of the specification. To a certain degree, style is also fair game during a review. Many organizations have guidelines around how code should be formatted and a code review is the perfect place to ensure that those guidelines are being followed. However, try to refrain from enforcing personal style preferences that go beyond the organizations requirements.
Next Steps:
- Read Software Engineering Best Practices: Code Reviews – Part 1
- Read Software Engineering Best Practices: Code Reviews – Part 3
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
David Hubbell
Software Engineer
SPK and Associates
