Re: PL/SQL Code Reviews

DA Morgan wrote:

> redrobot5050_at_gmail.com wrote:
>

[...]
>
> The biggest issues around code reviews are:
> 1. Management must have the background to mandate them and stand
> behind the reviewers.
> 2. Everybodies code must be reviewed ... that includes UNIX sys
> admins and their shell scripts as well as the code executed
> by DBAs as part of their "maintenance" function. It can not
> just be a "beat up on the developers" fest.
> 3. The person or persons doing the reivew must actually be
> competent ... not just have an important title. I have seen
> DBAs that couldn't write a decent PL/SQL package criticizing
> code they quite frankly couldn't understand.
> 4. The persons reviewing the code should include (1) A subject
> matter expert, (2) the person that wrote the code, (3) at
> least a few members of the development team. This is done so
> that lessons are learned and spread through the group.
> 5. The "subject matter expert" is not the "expert" because they
> have been using Oracle since version 5, or 6, or whatever but
> is actually an expert on the version being used. I have seen
> Oraclasours (Oracle dinosaurs) who had never seen bulk collection
> pass as good code with cursors that was horrible just out of
> pure ignorance.
> 6. Make sure that the review is done as an educational event not
> as a lets make the coder feel like they are being personally
> taken to task event.
>
> <RANT>

>[...]> 

Well put. I first heard the term "two sets of eyes" applied to programming quite some time ago.

"The important thing to understand is the principle behind pair programming – two sets of eyes looking at code. Two sets of eyes catches errors that may show up later in full testing. A second set of eyes can tell how readable is your code."

How two-years-ago! ;-)

http://www.artima.com/forums/flat.jsp?forum=106&thread=20073 http://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/pairprogramming.html

-Mark Bole Received on Thu Sep 15 2005 - 20:40:49 CDT