Re: PL/SQL Code Reviews

Billy wrote:
> redrobot5050_at_gmail.com wrote:
> >
> > Has anyone here ever participated or lead an group in a PL/SQL code
> > review? My project manager and I believe that our we need to
> > incorporation a code review/inspection into our process and I am trying
> > to assemble a list of resources that should help us in accomplishing
> > this task.
>
> Code reviews tend to be a negative experience for developers. Not that
> I mind grabbing the old lead pipe and beating up developers over bad
> code in production.. but that seldom achieves the desired result.

If participants enter with the idea of beating up the coder, then who's suprised at the coder getting bruised? This should not be like ORAL exams for a doctorate degree. The goal is better code and some team communication.

A little training of participants goes a long way toward preventing the negative results. Just the simeple reminder that it is a CODE review, not a programmer review helps. Everyone, including the coder needs to be reminded occasionally.

>
> Why are code reviews needed? I believe that question should first be
> asked. And then solutions must be looked at. In my experience the prime
> one is education. Get the developers' skills to a common and acceptable
> level. Get them to understand why it makes sense to follow the
> development standards set, show them the goalposts so they know what to
> aim for.

And like a marriage, there will have to be some compromises to be successful.
>
> Of course, not that easy. What did work and worked well is when we did
> an outsource job many years ago using external sub-contractors for
> development. The first week for a new group of contractors was
> dedicated to training. I gave them the specs for a minor subsystem
> (already developed) that was about 3 man days worth of development. The
> week (5md's) was spend by the new contractors developing that subsystem
> in a dev environment. This was the ideal environment for them to get
> their feet wet, make mistakes, and learn from it.
>
> After that week, they were fully productive and turned out quality
> code. I reviewed their code as part of my Q&A duties, but it was minor
> and nothing like these full blown (and often confrontational) reviews
> one tends to get. And 90+% of the code was really quality stuff. Sure,
> the 1st 5md's was training at our expense. But we got a lot more back
> on that investment in the end.

Exellent example.
>
> We had the occassion where a contractor kind of failed this 1st week's
> training. We terminated their contracts immediately.
>
> Obviously this situation we had was unique in that it did not have to
> deal with existing "entrenched" developers that are use to doing things
> in a specific "non-standard" (hackish?) way. Still.. I believe that
> this type of approach to training and evolving skill levels is far more
> beneficial than code reviews.
>
> --
> Billy

One rule (of many) we used at a place that did Inspections is that the coder owns the code. So even if reviewers say, change this, reformat that, etc., the coder has to respond but the response may be to ignore the advice. This empowerment reduces the stress levels all around.

And a final point. There are many ways of doing these reviews. Simple desk checks, Execution reviews, unstructured reviews, structured reviews, and software inspections. The unstructured reviews most easily break down to beat-up-the-developer sessions. Whatever you do, the process needs some clear guidelines AND practice. (try getting some code not done by anyone on your team and seen how you all deal with it, so there's no team member feelings to hurt).

 HTH
  Ed
(I'm no guru, but I have successfully used just about every review process at one time or other. Being a contract engineer can provide a wide range of experience.) Received on Fri Sep 16 2005 - 15:01:24 CDT