Re: Best practices

From: Daniel Morgan <dmorgan_at_exesolutions.com>
Date: Wed, 03 Jul 2002 19:29:56 GMT
Message-ID: <3D23508E.387D3F7C@exesolutions.com>

Ed Prochak wrote:

> Ryan wrote:
> >
> > "Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
> > news:3D1C85F3.61A452DD_at_exesolutions.com...
> > > Niall Litchfield wrote:
> > >
> > > > I am in the process if reviewing and rewriting our Database Policies
> > > > documentation. I was wondering if there are any useful best
> > > > practices/policies documents out there in internet land that might be
> > useful
> > > > to me.
> > > >
> > > > --
> > > > Niall Litchfield
> > > > Oracle DBA
> > > > Audit Commission UK
> > > > *****************************************
> > > > Please include version and platform
> > > > and SQL where applicable
> > > > It makes life easier and increases the
> > > > likelihood of a good answer
> > > >
> > > > ******************************************
> > >
> > > Likely but I would like to propose my favorite in case you don't find it
> > > elsewhere.
> > >
> > > 1. No piece of code, whether new or upgrade or bug fix goes into
> > production
> > > without going through a quality control step in which the testers are
> > > independent of the department that generated the code.
> > > 2. No piece of code, whether new or upgrade or bug fix goes into testing
> > without
> > > going through a code review conducted by senior developers and attended by
> > all
> > > developers on the project.
> > > 3. No project produces any piece of code without the project having a lead
> > that
> > > is truly a senior developer with the language being used and in the
> > environment
> > > in which it will be deployed.
> > >
> > > These three alone would eliminate 80%+ of the mistakes I see.
> > >
> > > Daniel Morgan
> > >
> >
> > I have a question about #2? Doesnt this really slow down productivity? My
> > group has a test team and we have an independent Q/A team that re-tests
> > everything before going into production.
> >
> > Are you talking about peer reviews for everything? I have done these before
> > and they are incredibly time consuming. Documents, then everyone needs to
> > read them, then a review and questions... Not sure how you can do that for
> > everything.
> >
> > Is that what you are recommending? Does code review include minor DB tuning
> > changes? Such as new indexes, etc...
> >
> > Just curious how you do things.

>

> Companies that do at least code reviews have fewer bugs and so less
> mainenance work. There IS a net savings. If it really is a small change,
> then the review can be short. Adding a new index is really a performance
> issue and needs to be reviewed as such.

>

> Or do you really like it when testers (or worse customers) find problems
> in your code? Reviews don't get rid of all bugs, but the ones they do
> find are a lot cheaper to fix.

>

> --
> Edward J. Prochak --- Magic Interface, Ltd.
> Ofc: 440-498-3700
> on the web at --- http://www.magicinterface.com
> email: ed.prochak_at_magicinterface.com

And yes I am definitely talking about peer review of all code ... once before it is written and once after it has passed unit testing by the developer.

QA people can catch obvious mistakes. They can't catch subtle ones. I'll give you an example from a project that I worked on at one of the nation's largest banks.

The code:

IF acct_type = 'A' THEN

   commission_pct := X;
ELSIF acct_type = 'B' THEN

   commission_pct := Y;
ELSIF acct_type = 'C' THEN

   commission_pct := Z;
END IF; If you can see what is wrong, and it is pretty obvious, great. But it managed to stay in their system for almost a year.

What is important is to recognize is that error is so subtle that no QA technique known, other than a code review, could possibly catch it.

If you can't catch it then ask and I'll add it to the thread. (and if I made some silly syntax error ... that's not it).

Daniel Morgan Received on Wed Jul 03 2002 - 14:29:56 CDT