Re: PL/SQL Code Reviews

redrobot5050_at_gmail.com wrote:

> 1) We will probably move to 10g, so eliminating any deprecated
> functionality from 9i is going to be important

Deprecated functionality exists but is minor. Far more important is new 10g functionality and techniques.

For example before 9i you would never analyze data dictionary tables. In 9i it become "ok" but not necessarily recommended practice. With 10g it is best practice. If you don't understand system statistics and the capabilities of the DBMS_STATS package you will not achieve your goal.

> 2) Most of the commenting is out of date

Good place to put those writing documentation.

> 3) Style is inconsistent because we still argue about what is "most
> readable" or "proper format" for PL/SQL syntax. (*not trying to start a
> flame war here*)

More like a religious war. I'd suggest finding an authoritative, and neutral source, and use it as the decision maker. My personal recommendation would be asktom.oracle.com and Tom Kyte's books. Everyone on the team will prefer what they do and that others change. By choosing a guide that is highly respected and not on the team you can avoid the hurt feelings.

> 4) As a small team, criticism needs to be constructive, so that we all
> continue to work well with each other.

That's what beer is for. ;-)

> I think some of the barriers i'm facing are:
> 1) We all have different coding styles. We really need to settle on
> one. I'm reluctant to bring this up, as this seems like something petty
> or something "the newbie" would bring up (when there are probably more
> pressing issues that need to be addressed) but readability is (in my
> mind) part of a code's maintainability..and let's face it, beauty.

As I suggest above. Use a neutral third party as the model: I personally recommend Tom Kyte.

> 2) We are close to a "go live" date. Odds are, we would be fixing those
> defects found through a code inspection after the "go live" date. We're
> all expecting that once the system is turned on, the parts of the
> system that had little or no requirements will become better defined
> through user feedback.

Feedback? What a nice euphemism for complaints.

> 3) There is still some of a "if it isn't broke, don't fix it mentality"
> going on in the development team. We know that trying to condense the
> code into something more elegant could be an ugly, uphill battle at
> first. And something like that would require a full systems test by the
> QA team, which is swamped with last-minute items before we "go-live"

Then start working on the .1 release.

> so how do I convince my team that the payoff at the end is worth the
> uphill battle?

As the junior person on the team this may be difficult depending on personalities. And this really is an issue of personalities rather than substance. If the more senior members can't figure this out on their own then they are senior by age rather than experience.

> Thanks again all,
> CW

The person that needs to be convinced that code reviews and well documented easy to manage code is an advantage is the CIO. If that person doesn't buy in it isn't going to happen. And if that person is not bright enough to have done this on their own I'd suggest updating your resume. You are in for a very frustrating experience.

-- 
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)