To properly implement code reviews and alleviate concerns, teams must educate themselves on its benefits and purpose. The following section outlines what code reviews aren't and what they are.
Code Reviews Aren't:
- They are not a grading and ranking system for developers.
- They do not have any bearing on performance reviews.
- They are not an opportunity to change someone's coding style.
- They are not a time for criticism or negative comments.
- They help spread team knowledge about features.
- They help identify possible logic or business gaps.
- They are an excellent way to learn new tips and tricks for both parties.
- They are a time for constructive feedback.
Code reviews should be a team activity with all members participating. Enabling each member to be a reviewer encourages trust, constructive conversation, and increases socialization. Don't forget, the learning process can go both ways. The reviewer may pick up a few coding tips as well. Performing a review should be very informal. When coding is complete (or possibly before), a team member should request a review from another member. Do not rush through the review. Show the same respect one would show to his/her own code. The purpose of the review is to understand the problem and how it was solved. It is not a witch hunt to find an issue. If everything looks good, a simple "looks great" will suffice. It does not need to be more complicated than that.
The results of performing code reviews are quite clear. Over time it elevates the code of the entire team. It also acts as an excellent mentoring tool for new or junior developers and provides invaluable one-on-one time with experienced team members. Even with these benefits, some still cringe at the words "code review." In an attempt to remove this stigma, some in the developer community have changed the phrase to "peer review." This is a positive change as it reinforces the team benefits and shifts the focus towards responsible team coding.