(^28) 97 Things Every Programmer Should Know
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 pro-
duction. 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. Shar-
ing 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 the code by trying to learn
and understand it.