Code Reviews, do I really have to?

I have worked on many different teams, and code reviews have been mandatory on some, optional on others, and flat out not done on others.  In addition, code review as a term seems to have a very vague meaning that’s open to interpretation.  I would like to share some of my experiences with code reviews, and what some of the benefits are of them.

First off, let me share that I am a believer in code reviews done right.  I believe they are a fantastic tool for learning new techniques and sharing knowledge in a team when done right.  In addition, they tend to help produce higher quality code by being promoting proactive quality checks in performance, overall code quality, and potentially business logic.

So there are generally 2 styles of code reviews I’ve experienced.  Each has its own strengths and weakness.  The first style I will call “Delta Based Reviews”, which tends to be done more frequently on smaller chunks of code and tends to focus more on the quality aspects of review rather than the learning aspects.  The second style I will call “Presentation Based Reviews”, which tends to be more of a group exercise done less frequently.  This style tends focus more on the educational aspects of code review.   I will spend the rest of this blog discussing these 2 styles in more detail.

Delta based reviews can happen very frequently, and be performed by a single peer, or the entire team.  Delta based reviews utilize version control systems such as TFS, SVN, GIT, Mercurial, etc. to determine all of the code changes done in a branch, commit, or changeset.  The reviewer will select the appropriate unit from the version control system and review all of the changes to code made in this unit.  Reviewers typically disregard any unchanged code as irrelevant to the code review.  Typically the reviewer will look for any glaring bugs or performance issues in these reviews.  If the scope of the change is significant the reviewer may look into things like architecture and design to insure that the code is meeting minimal organizational standards, and provides appropriate levels of future maintainability.  These types of code reviews work as an excellent part of the quality assurance process.

If they are done on a frequent basis they can catch issues quickly while they are still on the developer’s mind before the code is ever deployed to other environments.  I have worked with these types of review at three levels of frequency: by release, once a week, and for every development feature an individual developer has worked on.  When these types of code reviews happen on a more frequent basis they become an invaluable tool in the quality assurance process.  However, they can also cause the reviewers to pay less attention in the review than they should if they are overburdened by too many code-reviews all the time.

The second style of code review, which I call the “Presentation Based Review” is based more on presenting new APIs, or new architectures to a team.  These reviews tend to be more aimed at educating a development team on new pieces of code that are available to the team.  However, they also provide the team with the ability to provide feedback to better optimize the APIs being presented to them.  These type of code reviews can also lead to review of the business functionality being provided, and can occasionally benefit from having a business analyst involved to provide feedback for questions that may arise during the review.

Presentation Based Reviews can also morph out of the “Delta Based Reviews” by providing a chance for code reviewers to discuss the results of their delta based reviews with the team.  One or two presenters may choose to discuss the results with the team to help them learn better performance and maintenance coding techniques.  Remember, the objective of this type of review is not to humiliate any single developer, it is to help the team as a whole learn and grow.  If possible try to hide the developer’s name whose code is being presented, unless they are ok with their name being used.

When code reviews are done right the provide a great mechanism to improve developer knowledge.  However, be careful not to turn code reviewing into a chore that must be done on a scheduled basis.  Also, do not force code reviews on to your team just for the sake of doing code reviews.  Teams that understand the benefits and objectives of code reviews have the opportunity for excellent growth.  There is more to gain from the collective wisdom of the group, and that is the ultimate objective of the review.

Leave a Reply