RE: Code reviews

["Kirk Elder" <kelder@Ariba.com>]

Hi Eric, and all, this is a subject I have spent some time thinking about as
well.  Code reviews do not need to be line-by-line syntax checkers,
generally the tend to be more like a "code design" or Implementation
walkthrough.  This level of review can be very important.

The depth of code reviews, design reviews, and even design documentation
should all be done on a case by case basis, and I think are directly related
to how you think the project will scale long-term.  By this, I mean, if the
code is "throw away code", you obviously do not need bunches of the review
and documentation.  However, if you are working in a large dev shop, and
your code is adding to large mass of complex code, then the more controls
you might need to make sure that your code satifies the prescribed features,
while still remaining simple/organized/efficient enough for gobs of other
people to understand and maintain.  

In IT shops, typically what you see is lots of smaller projects (smaller
than the large dev shop).  The danger here is that people tend to think that
their small project, really does not matter too much, that a code review
might not be warranted, that design documentation, or implementation
documentation is not important, and that nobody would understand it if they
did.  This is very dangerous.  I have consulted at companies that had
thousands of undocumented modules running, without anyone knowing anything
about them.  They were all written years ago, and the proper knowledge
transfer had not taken place. Places like these need a CSO, Chief
Simplification Officer, to champion efforts to cut down on the maintentace
costs and RISK of such an environment.  

If the average code review can cut down on the creation of one or two
methods per class, or even one or two classes per sub-project, over five
years this can equal a lot of unneeded code.  Furthermore, if a code review
allows at least one other person to stay up to date with your code, then
when you get hit by a bus, some of the intricacies of that code will not be
so difficult to figure out later.  Turnover in todays tech world contributes
a lot of this inefficiency, and the company must maintain knowledge of its
operations through dissemination and strong leadership.

Many people do code reviews because you are suppossed to, but if you can get
your project team to take the right attitude, from a higher level, it really
can help.



-----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