Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: PL/SQL Code Reviews

Re: PL/SQL Code Reviews

From: <redrobot5050_at_gmail.com>
Date: 15 Sep 2005 07:46:32 -0700
Message-ID: <1126795592.760956.139350@g49g2000cwa.googlegroups.com>


Guys,

Thanks for the advice. It sounds like you two have undergone some serious code reviews.
I want to give a little bit more background and see if you have any advice.

I'm the new hire to a 3 year old project. We are a small group, with only 3 full time developers and a 3 man QA/Documentation staff. I am the juniormost of the 3 developers, both in experience to the project, and experience in PL/SQL programming in general. We are building a web app usnig PL/SQL and Oracle 9i's Web Application Toolkit.

My manager has felt that a code review has been necessary for a while, because all of us have griped from time to time how difficult it can be to integrate enhancements or requirement changes into the existing workflow. My project's worst enemy is that our requirements were poorly defined, and not verified. That aside, management feels (as well as I do) that a code review should be done.

Things we want to keep in mind:
1) We will probably move to 10g, so eliminating any deprecated functionality from 9i is going to be important 2) Most of the commenting is out of date 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*)
4) As a small team, criticism needs to be constructive, so that we all continue to work well with each other.

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. 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 not requirements will become better defined through user feedback.
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"

so how do I convince my team that the payoff at the end is worth the uphill battle?
And more importantly, does anyone have any other criteria to add?

Thanks again all,
CW Received on Thu Sep 15 2005 - 09:46:32 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US