Any tips for a group needing to start code reviews? We have no real software engineering processes currently. I have been working as software engineer for 7 years and have never seen any real processes implemented at the various places I have worked, though many books espouse all kinds of engineering methodologies. The management supports the idea of enabling new processes, though there is some resistance from the senior engineer who has over 20 years of software engineering experience.

We are a set of two programmers, with no software engineering manager. We report direct to the managing director of the Company. But we work on numerous software projects. The real reason why we have to begin performing code reviews is because of PA-DSS requirements. Therefore, I am pushing for us to do code reviews all around - not just on the payment application software.

  • I'm not sure what your actual question is. If it's just "Do you have any tips?", then that's an open-ended discussion, and these sites are about focused, answerable questions (though discussions are welcome in chat). If it's about convincing people to do something, that would be off-topic as it's not really a programming question.
    – Ixrec
    Nov 15, 2015 at 13:18
  • @Ixrec: And this was closed over 5 years ago, so why are you commenting? Nov 16, 2015 at 13:05

3 Answers 3


Since there are only two of you, theoretically you do not really need a formal review process. What should be happening is that when one of you finishes a piece of code he should simply say to the other: "Here's what I did. Please take a look."

This, of course, assumes that both of you are reasonable, sufficiently disciplined, and that you both have a sufficient grip on your own egos. If these assumptions are false, then you do need a formal process enforced from the top. The simplest thing to do is to make a rule that all commits or merges to the trunk must be looked at and approved by the other person, or at least one other person, in case your team grows.

This does not apply to you yet, but in my experience formal code reviews by even a team of 4 people end up taking way too much time, and 90% of the comments from individual reviewers are the same. That's why we switched to this one-reviewer system.

  • 1
    On your last paragraph: if you're doing multi-person reviews it should be in series, not in parallel. Tools such as Atlassian Crucible can make it easy to annotate code with review comments to allow this in a nice way, (although if you don't want things too formal the default config does need altering). (Probably many of the tools in Andrew's answer can do the same - not tried any of those myself). Nov 11, 2010 at 16:01

You want code reviews to be a positive exercise! Here are some tips:

  • Code review early by pair programming! Even if this is only for 30 minutes a day.

  • Use static code analysis tools, style checkers and templates to get rid of the fluff. You can then concentrate on the meatier issues (SRP, design patterns, exception handling, coding to interfaces etc etc) which is what code reviews should be really about (IMHO).

  • Get an agreed checklist between you on what's important and what's not

  • Some sort of Test Driven approach (forces better upfront design) is recommended further down the track

  • There are some really good code review tools out there - I use Crucible personally

  • Make sure that an attitude of 'improve the code' as opposed to 'crticise the coder'. This is vital in keeping everyone's egos happy.

  • Do it regularly, don't skimp on it. Either after a group of commits or 1/day or whatever you agree on.

Good luck!


Easiest way to start code review: just start doing it with one of open-source review tool. http://ostatic.com/blog/open-source-code-review-tools You may start from simple process: every day one developer review code of second developer and vice versa. If review will help you improve your code, than you may think about "real tech process"

  • I have never used any of these tools.. I assume they look at your code to figure out what changed and produce a sort of diff so the reviewer can easily review and comment? This seems like it would be a good start. Nov 11, 2010 at 23:09
  • 1
    Yes. They are working that way. And remember about only one valid metric of code quality :) telio.be/blog/wp-content/uploads/2008/10/wtf-metric-3.jpg Nov 12, 2010 at 11:43
  • @AndrewFrolov Please note, your JPG link is broken (404). Dec 10, 2013 at 12:05

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