On my dev team, we're doing code reviews, however not in a proper way i believe.

The issues our process suffers from:

  1. Not enough time is allocated for proper code review.
  2. Doing reviews is not mandatory - many times it is simply not done.
  3. Devs sit together for reviews, due to lack of another easy mechanism for doing it "offline" without spending both developers' time.

My question is: can integration of a tool for code reviews improve the points mentioned above? Is it not needed?

I would love to hear from positive/negative experiences.

  • 5
    Having a code review tool will definitely improve the issue of not having any code review tool. – che Oct 17 '13 at 21:35
  • 1
    The problem I have with your post is that you say you don't like your current situation, and then propose solutions. Issues 1&2 are completely unrelated to tool question you pose and already imply how to resolve them, and issue 3 just says not having a tool sucks. I have trouble finding what are you actually asking. – che Oct 18 '13 at 11:13

By actually enforcing code reviews with tools like gerrit or Crucible you can solve part 2 and 3 of your problem. Part 1 is more a process / social problem you'll never fix with software.


No you're not doing code reviews properly (obviously!). So the question remains whether there's something wrong with your code that it needs review sessions? (ie if you're shipping working code, code reviews are a solution looking for a problem).

If you think they would be beneficial, then I'd start work with a code review tool you can use in a 'as and when' mode - so you upload a code review request but it doesn't stop the rest of the process of committing and building code from happening. I think if you added the review to the workflow process that prevented commits until after review, you'd just end up frustrated and sidestepping the reviews. Be honest with yourselves in this case.

But if you could review code when you have time, then it becomes a good way of showing what you did to solve a work task, and you can always retroactively fix code review defects by raising a subsequent bug.

Good code review tools are ReviewBoard - a python base website. You upload diffs to the site and can then assign and comment on them. VMWare developed it for their own purposes. Gerrit works well if you use git. Redmine has a nice code review plugin that allows reviews based on any commit, you just create a new review as just another tracker ticket. Its pleasant to use and doesn;'t get in your way.

  • 1
    "if you're shipping working code, code reviews are a solution looking for a problem"? Whaa?? Is working code the only criterium in your standards? – Marjan Venema Oct 18 '13 at 12:47
  • What is your definition of working code? Reviews are there for checking things your test won't find. (Think of wrong assumptions, for example.) Neither one nor the other are sufficient on their own if you want high quality code. And if you do sometimes code reviews and sometimes not you have some inconsistency in your process, leading to confusion and maybe higher diversity in code quality of the project. People will question the workflow and try to make it consistent, as the question shows. – TheMorph Oct 18 '13 at 15:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.