Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Code Reviews: Understanding and Breaking the Stigma

12.19.2012
| 4677 views |
  • submit to reddit
The phrase "code review" can evoke a negative or emotional response from many programmers. The negative undertone stems from the perceived judgment of their work. It transports them back to the grade school stress before a final exam. Why is this? Like other professions during the industrial age, programmers build software with their hands and minds. Although it may look structured, programming is an art form. No two individuals have the same style, but they are proud and take ownership of their work. Passion is a large driving force in software development. Most individuals are concerned about how their work will be judged.

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.
Code Reviews Are:
  • 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.
Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)