Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> Re: PL/SQL Code Reviews
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