Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!oscsuna.osc.edu!pixelpump.osc.edu!stein
From: stein@pixelpump.osc.edu (Rick 'Transputer' Stein)
Newsgroups: comp.software-eng
Subject: Re: code reviews
Message-ID: <214@oscsuna.osc.edu>
Date: 16 Jun 89 15:19:12 GMT
References: <12047@bloom-beacon.MIT.EDU>
Sender: news@oscsuna.osc.edu
Reply-To: stein@pixelpump.UUCP (Rick 'Transputer' Stein)
Organization: Ohio Supercomputer Center
Lines: 51

In article <12047@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>At the request of one of our clients, my company is about to have it's
>first code review.  I've read a fair amount about the benefits of code
>reviews, but very little on methods or procedures.  
First question:
Are you in a DoD or ANSI environment?  If you are DoD (2167), and you've
never experienced a Critcial Design Review, are you in for an _EXPERIENCE_.!
If its ANSI, well, its only 80% of DoD -:).
>
>Among the 30 other programmers here, only 2 (that i know of) have ever
>been invovled in a code review.  From talking with them, i gather that
>there are typically two kinds of reviews -- formal design/functionality
>reviews, and informal peer reviews, covering implementation details.  
Actually, this is really a function of corporate policy.  Meaning that
the presentation materials needed for each kind of formal review are
usually stipulated by the program director, etc.  Basically your are right.
System requirements reviews, preliminary design review, critical design
review are usually the primary customer interfaces.  Code walk throughs
are more generally used one on one with a supervisor and a staff member
to examine what the software physically looks like.  A critique of the
code is conducted (like compute the constant up above and then add it 
to speed the loop, mostly cosmetic stuff).
>
>The review requested by the client is supposed to be a formal algorithm
>and functionality review.  We have a fairly good idea how to handle that
>-- the client is really only interested in making sure someone else
>(mainly the project manager) has looked at my program and verified that
>it's correct (above and beyond normal testing that would be done).  
Sounds like a Critical Design Review to me.  This is the phase in the
SWLC that occurs just before coding begins.  Usually you present DFDs
HIPOs, Flowcharts, and other design data.  Sounds like you've already
had a code walk through, so you're clearly beyond the CDR in the SWLC.
You might want to show the unit development folders.
>
>Since part of my job here is to improve programmer productivity, i'm
>interested in eventually implementing some sort of procedure for
>periodic peer reviews.  Does anyone have suggestions or
>reccommendations?
If you have a style guide specifying the formalism to use when coding
software, this helps quite a bit.  That way you have a standard reference
and rule book to use as a judge and coach.
>
>thanks for any advice,
>michael j zehr
No problem.  Hope it helps.

-=-
Richard M. Stein (aka Rick 'Transputer' Stein)
Concurrent Software Specialist @ The Ohio Supercomputer Center
Ghettoblaster vacuum cleaner architect and Trollius semi-guru
Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122