Click here to Skip to main content
15,867,488 members
Articles / Operating Systems / Windows

Why You Want Code Reviews

Rate me:
Please Sign up or sign in to vote.
4.57/5 (7 votes)
4 Oct 2009CPOL7 min read 19.7K   13   5
This post discusses why you want code reviews

Lately, there have been some discussions in our team on whether or not code reviews are needed and even practical and why you should want them in your development team. This may sound like obvious knowledge, but unfortunately it appears that some developers have an aversion to code reviews, whether it is their code being reviewed or them reviewing someone else's code. In this article, we'll look into some of the reasons that make developers feel this way and also we look into some of the benefits of having code reviews. As we go through all this, we will also pay some attention to how to prevent bad experiences with code reviews.

Why Not?

As I mentioned in the introduction, there is still a fairly large group of developers who have an aversion to code reviews. A lot of the time, this is because they feel that they did the best job they could on the code they have built, given the circumstances and they don't need some coworker grinding their hard labor to pieces and giving them a hard time.

If that's the case, something is obviously wrong. If this feeling is based on previous experience, then they have experienced a bad code review by some reviewer who clearly missed the point.

Others may not want to be at that end of the table where they have to tell a coworker they did a bad job. Again, if you feel like this, you missed the point.

It is NEVER the goal to find something to be able to accuse the developer of bad work.

A third reason why a developer may not want code reviews is that they think it will be boring to do a review. If that's you, you guessed it, you've missed the point as well.

A fourth and final reason could be that developers think this will take up to much of their time to be valuable to them. Well, you're wrong!

The Goals of Code Review

So what are we trying to accomplish through a code review? There are several very important goals one could target:

  1. Code quality
  2. Code consistency
  3. Architecture consistency
  4. Awareness
  5. Knowledge sharing

Code Quality

This may seem like the obvious first reason and causes the most aversion. Sure a developer tries to do the best job he or she can, however we are all human so we make mistakes. The goal here is not to bang on someone's bad pieces of code, but to prevent bugs from happening. Bugs cause a lot of work for a software company. If they get caught by the testing department, they have to generate a case file for it and communicate that back to the developers, who in turn have to do rework and system test that. It then gets handed back to testing and they have to retest.

If a bug is discovered by a user, things get even worse. They will file a case with the support desk, who has to triage it and then it has to be planned for a release and generates a whole bunch of work. So in the end, it is in everyone's best interest to prevent bugs from happening, which is exactly what the first goal of a code review is all about. As you can see, time spent on code reviews is actually an investment to prevent having to go spend a lot of time on rework.

Code Consistency

To keep code maintainable, it is imperative that chosen solutions are consistent with each other. However, it is hard to know everything about a large code base that keeps expanding and changing while a team of developers is working on it. By having code reviews in place, a large part of inconsistency can be caught and fixed before the code actually gets to the testing department. Again, this will save time in the future as code gets easier to read and understand.

Architecture Consistency

From experience, I know it is hard to keep the architecture that was planned consistently throughout the system. Developers often tend to do things their way, especially when they either have difficulties understanding the architecture or how to solve a particular problem in the architecture, or because they run into time constraints.

To make sure that architecture at least stays consistent throughout the system, it is important to look at how certain functionality is built into the system. If a developer did something that affects the consistency, but brings a good argument for doing it that way, it may result in changes in the overall architecture because then chances are the architecture wasn't fitting the application. Again, this is important to the whole team as some others may end up feeling the same pains the first developer encountered if it doesn't get addressed.

Awareness

This may sound like a very generic term, so let me explain. Because we work in a rapidly changing field, there is no way to keep up with everything that's going on so at times we may miss certain information which would have helped us in solving a particular problem a lot easier or more efficiently or prevent some problem in the future. To keep us more up to speed, a reviewer may spot some of these issues and point out other possible solutions to a problem of which we might not have been aware.

Looking at this from a reviewers point of view, you might actually see some features you were not aware of.

Knowledge Sharing

This is a more obvious benefit. Not only does the developer get a chance to learn from the reviewer, but it also works the other way around. And this doesn't only apply to technical knowledge, it also goes for specific knowledge about the application that's being reviewed, which is an important business benefit.

Tips on Code Reviews

To make code reviews be a pleasant experience, both the developer and the reviewer need to keep an open mind. That doesn't mean you can't defend something you think is good work, or you can't say it when you see something you feel should be improved.

As a developer, look at this as an opportunity to showcase your code to one of your peers. Reviewers, ask questions. They allow the developer to explain choices he or she made in the process. Both parties shouldn't be pushing something without a good explanation. If you can't come to an agreement on an issue, involve a third party you both trust and stick to that decision. Also don't take it personally, opinions can differ and there are more ways than one to reach a goal.

To take full advantage of code reviews, there should be a group of reviewers who should be experienced developers in general and in the technology used. Also make sure the right reviewers are paired with the right developers. It's likely that a young but bright developer could review a more senior developer and technically this may make sense. However in the 'food chain', this might cause problems, so it's better to avoid this. On the other end of the spectrum, a young developer with less experience on the technology used might be intimidated by a review from the most senior developers on the team. This might lead to the young developer not speaking his or her mind and just following the senior developers. Although this might get the junior developer a long way, it will not teach him or her to have a mind of their own.

For educational purposes, it would be best to have a intermediate developer review a junior developer and have senior developers review intermediate developers. This way junior developers will be less intimidated and intermediate developers can learn the review skills from their seniors.

Conclusion

I agree that there is a lot to think about when implementing code reviews, however I do feel it is worth the effort. A team doing good code reviews will get great benefits from them. Consider it and if you feel like it, please share your experiences with us.

License

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


Written By
Software Developer (Senior) KnowledgePlaza
Netherlands Netherlands
Since early 2001 I've been working full time as a software developer and since 2004 I've been working mostly with Microsoft technology.
I started out as a product developer, but after a few years I switched to a project company where my roles ranged from developer up to consultant and from team lead and coach to manager.
Eventually I switched jobs and focused on the consultant part and then I got back to building a product once again. Now I work in a job where I get to do both.

Comments and Discussions

 
Generalwell done Pin
Donsw29-Oct-09 15:30
Donsw29-Oct-09 15:30 
GeneralRE: Code Reviews Pin
TroyAddison13-Oct-09 2:55
TroyAddison13-Oct-09 2:55 
GeneralRe: RE: Code Reviews Pin
mrjvdveen11-Nov-09 22:48
professionalmrjvdveen11-Nov-09 22:48 
GeneralReview before starting to code Pin
Rolf Kristensen28-Sep-09 22:58
Rolf Kristensen28-Sep-09 22:58 
Have found that doing a simple design specification really saves a lot of time.
* Less confusion between developer and customer about what is wanted
* Allows other developers to review the intended modifications, with easy transfer of knowledge.
* Any problems about difference in requested-solution and actual-solution can use the design-specification as reference.
* It will help to uncover any demands that might increase the time-estimate too much.

The design specification includes the following:
* Problem-description (usually 3-5 lines) usually written by the customer
* Solution-description (usually 3-5 lines) that can be written by the customer. Both customer and developer can write this.
* Demand-list (usually 5-10 lines) that specifies what changes in the code are needed to implement the specified solution. Always written by the developers.
* Test-cases (usually 5-10 lines) that specifies different use-cases the implementation should be able to handle. Both customer and developer can write these.

Design specification life-cycle:
1) Customer wants a problem solved
2) Customer might already have a possible solution and test-case, if not then a developer will go in a help to find a solution together with the customer.
3) Developer provide a lists of demands required to implement the solution. If coding effort is more than a week, then it must be split into multiple specifications.
4) Peer-developers are invited to comment on the solution and the demands. Maybe add white-box test-cases.
5) During development the developer will use demand-list as a check-list, and update it as the development progresses.
6) Customer is given the implemented solution, and verify it through the specified test-cases.

Btw. usually it will be a Customer-agent inside the development-firm, that will take the role as Customer.

Btw. in your list of why-not reasons to code-review, then you should include time-consuming. And include the pro-arguement that will save time as it will lower the amount of bug-fixes.
GeneralRe: Review before starting to code Pin
mrjvdveen4-Oct-09 20:31
professionalmrjvdveen4-Oct-09 20:31 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.