97 Things Every Programmer Should Know

Chapter 14. Code Reviews

Mattias Karlsson

YOU SHOULD DO CODE REVIEWS. Why? Because they increase code quality and reduce defect rate. But not necessarily for the reasons you might think.

Because they may previously have had some bad experiences with code reviews, many programmers tend to dislike them. I have seen organizations that require that all code pass a formal review before being deployed to production. Often, it is the architect or a lead developer doing this review, a practice that can be described as architect reviews everything. This is stated in the company’s software development process manual, so the programmers must comply.

There may be some organizations that need such a rigid and formal process, but most do not. In most organizations, such an approach is counterproductive. Reviewees can feel like they are being judged by a parole board. Reviewers need both the time to read the code and the time to keep up to date with all the details of the system; they can rapidly become the bottleneck in this process, and the process soon degenerates.

Instead of simply correcting mistakes in code, the purpose of code reviews should be to share knowledge and establish common coding guidelines. Sharing your code with other programmers enables collective code ownership. Let a random team member walk through the code with the rest of the team. Instead of looking for errors, you should review ...