Code Reviews 1 - Why?

I'd like this to be part of a series of articles on code reviews. Comments and suggestions welcome. There are as many views and opinions about code reviews, as there are developers. These are my views. I hope they make logical sense. They have been formed through my own experience.

Why do we do code reviews?

There are primarily two reasons why we engage in code reviews. Both are equally important.

Code Quality Checkpoint

For any "product", a review should be part of the production process - this goes from a set of accounts to a presentation. Reviewing one's work is a great practice for any craftsman to part-take in. There are two quality aspects that code reviews can help with.

Code Quality

How can I know that the software I have written is "good"?

Code is written once. Code is read many times. Frequent code reviews help me to write great code.

Code reviews help to have a good code base in the product. A "good" code base is one that is readable by a majority of programmers, without too much intervention by the Author. This has been expressed as the number of WTF per minute. We can ensure any style standards are consistently met.

Product/Component Quality

Code reviews are the also important for finding any possible bugs or errors in the solution we have put together. Since code reviews occur early in the production lifecycle, they are one of the cheapest ways of detecting and preventing issues.

Knowledge Transfer

Code reviews are a medium of communication between developers.

When we start out, we share our work with our more experienced peers so that we can learn. As we get wiser, we share our work with our peers to get their validation that we are doing the right thing. When we are at the top of our game, so to speak, with many years of experience we also take an active part in reviews to help pass on our experience and to get exposure to possible newer ways to do things that more recently trained developers will have learned.