Code reviews in most organizations are a painful experience for everyone involved. The developer often feels like it’s a bashing session designed to beat out their will. The development leads are often confused as to what is important to point out and what isn’t. And other developers that may be involved often use this as a chance to show how much better they can be by pointing out possible issues in someone else’s code.
Code reviews, however, don’t have to be painful.
Remembering the Purpose
Code reviews have two purposes. Their first purpose is to make sure that the code that is being produced has sufficient quality to be released. In other words, it’s the acid test for whether the code should be promoted to the next step in the process. Code reviews are very effective at finding errors of all types, including those caused by poor structure, those that don’t match business process, and also those simple omissions. That’s why they are an effective litmus test for the quality of the code.
The second purpose is as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.