Click here to Skip to main content
15,880,651 members
Articles
Technical Blog
(untagged)

Code Reviews: Understanding and Breaking the Stigma

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
12 Dec 2012CPOL2 min read 7.4K   2  
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.
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.
This article was originally posted at http://zacgery.blogspot.com/feeds/posts/default

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



Comments and Discussions

 
-- There are no messages in this forum --