I’ve been kicking around just how to go about implementing code reviews on my development teams for a month or two now. Despite my vast experience, OK only about 10 years or so, I never worked for an organization that practiced code reviews. I have done a few code walk-throughs myself to present some finished project to client development staff, but that’s about the extent of it.
So in collecting whatever information I could over the web and now having talked to several development managers who actually have some code review experience it appears that the consensus is you have to mandate them. I pretty much knew that since developer’s don’t naturally see the value in code reviews and they can often go wrong in so many ways:
- Nit picky tech leads who insist on minute changes.
- Harsh presentations where the developer is told over and over what they did wrong.
- Mind numbing code review meetings where everyone tries not to fall asleep.
So starting next week I’ll be mandating that all of my teams conduct code reviews. This goes against my basic personality of managing by consensus, but the benefits done right outweigh the discomfort of the situation. And if it goes horribly wrong we can always toss them out and try again later.
We have been using codestriker for over a year now and have found it extremely useful.
The advantages are that the reviews can be done based on the convenience of the reviewers. As soon as the reviewer enters a comment, the developer gets an email and he can enter a counter-argument to the comment.
We’ve had similar good luck using Jupiter (http://csdl.ics.hawaii.edu/Tools/Jupiter/). It’s a great Eclipse plugin. It’s easy to use, and it’s got a good community behind it. Here’s some stuff I’ve written about it (http://timshadel.com/blog/tag/jupiter).
Hmm. The comment didn’t pick up those links. Let me try this:
Jupiter Eclipse plugin
Zdot entries for ‘Jupiter’
Zdot entries for ‘Reviews’
I took a look at the Jupiter Eclipse plugin, and were we more of an Eclipse shop we’d probably be trying it out now. Still 100% of my group are IntelliJ users currently and there’s no plugin for IDEA. We’re dealing with Eclipse through RAD right now, but it isn’t anyone’s day to day IDE.
My idea is to start the process off pretty simple and a bit manual and then adjust from there. Thanks though for all the ideas.
I wrote an article on CodeStriker when we were first piloting it among a few of my people. Since then we have rolled it out and it seems to be working well. I would definitely recommend that you give it a try.
I’ve never quite figured out if I like code reviews. I certainly like the idea, and I can even believe it. But, in practice, I hate them ;>
One of my old friends has a company that sells a pretty snazy code review tool, Code Reviewer. I’ve seen it in action, and it looks like it would take away lots of the stuff I hate about code reviews. The main thing is that it allows you to time-shift the code review: you just ship click the button, and ship it to the person(s) to review it.
So, not to be too much of a shill, but Code Reviewer might worth checking out if you’re into getting a tool to help you.
I’d be interested in a follow up post on how the code reviewing is going. Like I said, I have a love-hate (mostly hate) relationship with them.
We’re still waiting to get going with the process. When you add a bunch of new tools/frameworks to every new project, things tend to slow down. For example most of my developers spent 2 whole days doing local installs of Websphere Portal Server 5.1.
One thing that most code reviews do that we’re not doing is not allowing people to check in files until they’ve been reviewed. We’re still allowing people to check-in early and often and relying on automated builds to catch big mistakes. The code reviews at this point are mainly to start conforming to coding conventions, and using similar patterns and techniques. Since this seems not to be the typical pattern we could be about to run into a lot of issues, but that’s what the experiment is for.