OraTransplant

Applying best practices from 3GL development

8 July 2005 at 20:02 CEST | In Database, Designer, Designer to JDeveloper, Forms, JDeveloper, Oracle, Other, Other, Other, Software development |

I’ve been looking at the tools used for 3GL development with some envy. There are tons of very productive tools available for Java, C++ and other 3GL developers. Wouldn’t it be great if we can use some of those for our Oracle Forms/Reports/Database development.

I’m planning on implementing some of those for our Oracle development in the rest of 2005 (and probably 2006). Hopefully this also closes the gap between our Oracle and Java developers. This is nice way for the Oracle developers to get to know some best practices from the Java development. Hopefully this makes a transition to Java a bit easier. I’ll keep reporting on this blog on my findings and perhaps publish a number of papers on how we implemented and integrated some tools.

The things I’m hoping to investigate (and perhaps implement) are:

Issue management
We could track bugs, features, tasks and improvements in a more professional way than we are doing now. This would also enable us to implement some workflow. I’m currently thinking about implementing JIRA.

Version control
Currently we do have some version control in place, but it is not as professional as I would like it to be. I will be evaluating both CVS and Subversion and we’ll probably implement one of these two. I tend to like Subversion a bit more but JDeveloper doesn’t support it yet.

Automatic builds
I would like to create automated builds as much as possible but at least daily. Refresh a database and an application server and apply all changes checked in to the version control system. During this automated process lots of checks and other tasks can be performed and monitored (also see other points). We might build this based on Ant and CruiseControl, since we’re already using these for our Java development.

Automatic tests
During the automatic builds I would like to perform as much automated tests as possible. This reduces the load on testers and can warn a developer early on that his change broke some tests. I’m looking at DBUnit and utPLSQL first.

Powerful editors
Currently we develop our PL/SQL code in Designer. The editor in Designer does offer color coding, but is not as powerful as other editors. Perhaps we should make JDeveloper or TOAD our primary editor. This would also enable us to offer all sorts of productivity enhancements to developers by using (custom build) plugins, templates and code snippets.

Formatting
If we would switch to another editor (JDeveloper or TOAD) I would also like to investigate code formatters. Using a uniform formatting of code makes it easier for developers to look at each others code. Also I found during Java development that Jalopy can save you a lot of time when writing code. It’s so nice to not bother about things like indentation and just run your code formatter to take care of it.

Quality Assurance
We have a lot of standards and guidelines for development. Wouldn’t it be nice if most of them could automatically be checked/enforced in your editor and during automatic builds/checks?

Documentation
If you’ve ever programmed Java, you must know JavaDoc. It’s a predefined way of adding documentation to every class and method and can generate quite useful HTML documentation for all your code automatically. Something similar exists for PL/SQL: PLDoc. It’s not much work for a developer to add comments using a fixed format but the generated HTML documentation can be a real treat. The editor should be able to help you here.

Logging
I want to have a look at the Log4PlSql framework. It’s designed after the Apache Log4J framework as being used by Java developers. It offers a way to add logging statements to your code which you can just leave in there for your production code. You can enable it at runtime and write the logging info to different outputs (database table, file, standard output, etc). No more hassling with adding dbms_output all the time and removing it again.

If you have any experience with these tools or methods and have some handy tips, please leave them as comment.