[Chicago] code review tools

Kumar McMillan kumar.mcmillan at gmail.com
Fri Aug 3 17:04:15 CEST 2007

On 7/24/07, sheila miguez <shekay at pobox.com> wrote:
> Don't you guys do code reviews?
> I'm talking anywhere from incredibly formal Fagen types of things to
> light-weight asynchronous things. Do I need to define this?

[once again late to the thread; it will never die - muhuhahahaha]

Apparently, yes, a definition needs to be stated:  Someone writes
code, another developer scrutinizes it, perhaps runs the tests, asks
why they are all failing, yells and screams, etc.  Code reviewing is
way different than pair programming because you can observe how a
developer thinks for himself.  I think people learn best by making
mistakes and a code review is about observing the mistakes then
explaining why/how to fix.  Pair programming promotes different
learning (i.e. show and tell) and has its place but at the end of the
day no one has time to pair program all the time (in my experience).

Anyway, I'm going to say something crazy, so brace yourself.  Our team
actually did an assessment of open source code review tools available
about 3 or 4 months ago (the django Review Board wasn't on the radar
then) and we went with Codestriker, written in *gasp* perl!

I have to say it actually works pretty well.  The interface is clunky
but the nicest thing is that you can enter in the svn work branch that
the feature was developed in and it will generate a diff against trunk
(you can also enter rev numbers or upload a diff).  When you want to
make a comment on a segment of code, you just click on the line number
and the reviewee can see that block of code in the comments view.  It
gets less granular then that: you can make a comment per file or per
overall diff.

Granted, we are still trying to make code reviews part of our regular
routine so we haven't had a lot of experience with the tool yet.  I
also plan to try out Review Board when I have time.

Similar to what Brian pointed out, we literally used to print out code
and gather in a conference room with a highlighter to do this sort of
thing.  Yes, code reviews are really important.  If I could sum it up
with some bullet points perhaps they would be:

 1. keeps the coder working diligently, knowing he/she is being watched
 2. lessens the chance for huge architectural mistakes to happen (+
better test coverage)
 3. keeps code consistent across the team

The company I'm at has been burnt by this so many times that the scars
are now unrecognizable.  Mostly by number #2.  [sigh].  Even the
quickest, simplest code review can shed stadium-strength light on a
situation.  I.E. "why is there a module called hacks.py?"


More information about the Chicago mailing list