Re: Code Review Process

From: rjamya <>
Date: Sat, 9 Feb 2013 09:26:36 -0500
Message-ID: <>

At my current job, we (dba's) manage any code change ourselves (DBA / Developer double duty) for anything more critical than a simple query, or if there is a very specific need. rest folks are java experts but they are very receptive to our opinions. We also have design review process when we build something new to decide what features (of oracle) should be used and how. We also have a formal code review process using crucible and assigned folks sign off. We review code together, ask questions but ignore variable naming etc, as long as it makes sense and sufficiently commented, it works. We ensure that critical pieces are logged appropriately into our logging table. java teams have started polulating module/action/client_info fields, so we can do further analysis via AWR as well. Then our performance management team beats the heck out of code java+oracle and we take results from there and feed it back to the team. Only then QA takes it over. So far it has worked very well, this is just an example, our teams work together (we all even sit together within shouting distance of each other) so communication is not a problem as well. But then since we do so much business aligned work, routine/very routine dba tasks are handled by another group, we just deal with our own set of databases, that is our domain.


On Fri, Feb 8, 2013 at 5:10 PM, Herring Dave - dherri <> wrote:

> Jeff,
> For the most part we're getting 1 to many scripts to run as a change and
> to blindly run them, sending the developers back all generated logs (we use
> a wrapper for every script so capture is the same every time) and updating
> the change ticket with that info. I try to spot check as sometimes they
> try creating tablespaces and make rather poor choices or try doing a "GRANT
> ALL" instead of listing the privs they really need. But for the most part
> there's no way we'd have time to check all code when we're on "change
> request" duty.
> Acxiom Corporation
> TEL 630.944.4762
> MBL 630.430.5988
> 1501 Opus Pl, Downers Grove, IL 60515, USA
> -----Original Message-----
> From: []
> On Behalf Of Jeff Chirco
> Sent: Wednesday, February 06, 2013 3:39 PM
> To:
> Subject: Code Review Process
> What is everyone's code review process?
> * Do you review code during development or right before going to
> QA?
> * Or do developers come to you and say we need this to go to
> production right now can you check it out really quick?
> * Are you proactive in the code review process or is there a
> formal submittal?
> And what is your code review process like?
> * Do you just check for naming standards? Use a special toll or
> application?
> * Do you do some kind of performance testing on the code? Do you
> do it on all code or just some
> Side question, which team writes your pl/sql code? Do have you dedicated
> pl/sql developers or do your Windows/Java/Cobol developers do the pl/sql as
> well? Our DBA team is very small so our .Net and Cobol programmers write
> most of their own pl/sql and since it is not their primary language it is
> not always the most efficient. So I am often reviewing it at the last
> minute with occasionally not much time to really make changes. I try to
> teach them as much as I can.
> Some background, we write all our own applications and it is all for
> internal use .
> Thanks in advance for any input.
> --
> ***************************************************************************
> The information contained in this communication is confidential, is
> intended only for the use of the recipient named above, and may be legally
> privileged.
> If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited.
> If you have received this communication in error, please resend this
> communication to the sender and delete the original message or any copy
> of it from your computer system.
> Thank You.
> ****************************************************************************
> --

Received on Sat Feb 09 2013 - 15:26:36 CET

Original text of this message