Ask a programmer why they do code review and you’ll get a different answer depending on the phase of the moon. There are lots of good reasons, but there is one killer reason that should be at the top of everyone’s list.
The one reason why code should be reviewed is to improve the quality of that code, and to do so at a time when it is still relatively inexpensive.
This may seem an obvious and redundant thing to say, but depending on the phase of the moon you’ll get one of the following answers;
- To share code knowledge
- To share best practice
- To learn new tricks
- To enforce a certain coding style
I want to put it on record that every one of these reasons is secondary to improving code quality.
What is code quality? I used to have a Zen-like attitude to quality, believing it too subjective and too ambiguous to be pinned down to a useful definition. These days I’m more pragmatic.
Software quality is its perceived value, depending on who is asking. For an end user, quality means usability and features. For a business owner, quality usually means ROI.
For programmers, software quality should be synonymous with maintainability above all else. Maintainability (it is unfortunate that it’s such an awkward word) means the ease with which a programmer can add or adjust features, and the ease of finding and fixing software bugs.
Related post: What’s wrong with this code, really?
Understanding code maintainability is the key to understanding the code review.
Think about it this way: just about every aspect of software quality can be comprehensively tested by tools or by a user, but assessing the maintainability of a software product is something that can only be done by a programmer. This is why maintainability should be the highest priority in a code review – it’s because no one else can do it except the programmer.
The programmer is the only person who looks at the code, everyone else looks at the product.