RE: Code reviews

["Bryant, William" <mbryant@c-cor.net>]

I'll respond to your question regarding single developer projects first:  In
my opinion single developer projects have a definite need for review.  I say
this because I have been in that position with some C/PHP written web stuff
I have done as a side gig.  When I do this kind of work (which always seems
to be around 2:00 am on some Saturday morning) I am, er, tempted to take the
occasional short cut.  And, I do sometimes succumb to the temptation to just
finish the darn thing and go to bed.  

Now, I have learned through more than a little pulling of hair at 3:30 am on
a Saturday morning (about a month after the initial release) that shortcuts
are not always a good thing.  And that little bit of convoluted code-- the
logic of which I was SURE I would remember-- well, was forgotten.  Of course
it works perfectly, I just have to re-write the whole thing to extend it
with new functionality...  So I do believe strongly in a code review for
single developer projects, even when the sole reviewer is the developer.

As for your questions about developers on other projects... You said '...who
have absolutely no clue as to the logic, design...'  I would prefer someone
review my design documents before evaluating my code.  If they have read my
use cases, glanced over my class diagrams, etc. then I will feel much more
comfortable in them reviewing the code.  Of course, I have reviewed a good
bit of code without first seeing design documents (and let's face it, many
times there ARE no design documents), and that works fine, but it does take
the reviewer a while to get the feel for the particular area of
functionality they are reviewing.

After saying all that, let me say that even more important (or at least as
important) than code reviews are design reviews.  It is a great benefit for
the developer to sit with a few folks that have a solid understanding of the
requirements and 'prove' the proposed design.  That means running some
sample queries on the proposed database tables, looking over the class
diagrams to see how they are extendable, etc.  For my single developer
projects, I usually do the design, let it sit for a few days, then come back
and see if I still agree with what I was thinking (amazing what a few days'
worth of not thinking about something will do for your outlook on it).  For
my projects here at my 9-5, I usually run my OO designs through one guy and
my database designs though another.  That gives me at least two people I can
get ideas from, and my design (and thus the code) benefits from it in ways I
can't even describe.

Hope all that rambling somehow helps...


... Mike



---------------------
Mike Bryant
Sr. Software Engineer
C-COR.net
mbryant@c-cor.net
770-814-0984 


-----Original Message-----
From: Minor, Eric [mailto:Enm6@cdc.gov]
Sent: Tuesday, August 14, 2001 6:24 PM
To: ajug-members@www.ajug.org
Subject: Code reviews



 This question is directed towards Project Managers, Team team leaders, but
all input is welcome.

First off, I realize the importance of doing code reviews for quality
assurance and  code efficiency.

But when is it warranted? Should programmers working on different projects
who have absolutely no clue 
as to the logic, design of someone else's project review the code for that
project? 

Would it be necessary for very small projects that requires only one
developer?

Certainly, it is a benefit for large scale projects with 3 or more
programmers.


Eric D. Minor
System Analyst III
404-498-0692