Re: PL/SQL Code Reviews

Ed Prochak wrote:

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

And if the coders "refuse" to comply - to understand the basics, RTFM, achieve enlightment, etc?

More than once I've had the occassion where new technology is used and developers insisting on using old concepts. It tends to get quite confrontational at times. That bit about leading a horse to water...

I do not mind if the issues is like demonstrating why soft parses are better than hard parses, or no parses (statement handle re-use) is better than soft parses.. or what the bindless SQL do versus bind SQL. Or the advanatages of bulk processing.

But what when the issue is a conceptual one and the counter arguments is based on ignorance of basic Oracle concepts? Refer them to the manual? Which they do not bother to read - ever? Spend hours and hours building test cases to show basic fundemental concepts? Thus I do tend at times reach for the lead pipe as I refuse to waste my time (I also have deadlines) with developers that refuses to understand fundamental concepts after I've explained in brief the concept with references to applicable Oracle manuals and documentation. (e.g. why ref cursors for doing HTMLDB reports is non-workable idea)

I think it is easier to deal with younger guys. They are still clean slates and can be taught. Much more difficult with older developers that believe that their development Kung Fu is of such a high standard that they know better than you.

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

Agree. But the Oracle University PL/SQL courses for example, seems to me very basic and does not teach/re-inforce fundemental programming and design techniques.

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

I have a problem with that - as I would sit in meetings with management and operations and have to explain why there are poor performance. Or deal with issues like snapshots too old, deadlocks and so on..

Is it too much to expect a certain quality in the code that is put into production?

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

Agree with you on that Ed. In fact, I dislike the idea of a code review entirely. If it comes down to that I would rather want to deal with the devloper alone on a personal level - not in a peer situation where egos are at stake.

--
Billy