Sunday, August 23, 2009

Why code reviews should be a teamthing

Often code reviews are done by one person, the technical lead of your team.

In my opinion it's better to make each developer of your team do code reviews.

My arguments
  1. Having all developers doing code reviews enforces well-documented coding standards..
  2. Which also leads to discussions about what these codings tandards should be.
  3. Each developer is forced to understand the workflow of an application which isn't his, which expands his domain knowledge.
  4. Each developer learns from others and is given an opportunity to teach and discuss why someone chose a certain path.. There is always something new to learn, even for seasoned developers. You might just pick up that latest trick doing whizbang Silverlight 3 stuff from that freshman that just started working this year.
  5. Multiple perspectives on a problem can only benefit the solution.

What are your thoughts?


  1. I agree , nevertheless it will consume time to discuss certain topics, it will benefit the overall quality of your team's development efforts

  2. We do team code reviews, but not as often as we'd like because it is a large investment in time.

    Our primary purpose in doing it this way is to share knowledge via the team. If our objective was to raise the quality of the code, i.e. to review for code quality, then I would not do it in teams.

  3. We do team code reviews of all code written. We have a policy that at least 2 people have to review any code written and sign it off.
    I disagree with Steve saying it is a large investment of time, not doing code reviews greatly increases your risk of bugs and building up of technical debt.

  4. @Pieter: Do you have well documented codingstandards? What happens when their a lot of different opinions on a subject?