Automated Code Generation (Page 6)

<< Introduction & Message Forum

<< Page 5 (Advantages & Disadvantges)

Generators and Agile Projects

Often, the prospect of making even a simple change to the database can strike fear in the hearts of the programmers.

Middle-tier code (business objects, entity beans etc) are supposed to lessen the dependency that the source code has on the database design. In reality, these additional layers simply increase the amount of code that must be rewritten when the database is changed. Add to that the other parts of the system that can be affected by a database change (or even worse, a change in a business process) - UI elements such as JSP pages and components, combo boxes, validation classes, state machines, business rule validators etc - and it soon becomes a genuinely scary prospect to make even a small change.

Agile methods help a lot, of course. Refactoring can help to reduce the amount of interdependent code; agile modeling can reduce (or even eliminate) the amount of refactoring that needs to be done; unit tests help to catch insidious problems that creep in during such changes; incremental change (i.e. making the change in short "baby steps") can also help, so that the design change is gradually nudged into place.

However, these methods are more about making changes safely than making them quickly. A simple change in the architecture can still have far-reaching effects throughout your codebase, resulting in a time-consuming "nudge-a-thon" to make the required changes in full and catch all the resultant problems.

If a large proportion of the codebase is automatically generated, then the prospect of a simple database change is suddenly not quite so terrifying. Simply make the change, then crank out a new version of the project.

Adding code generation techniques to your agile toolkit can make your project ultra-responsive to changes in both requirements and architecture.

>> Page 7 (Conclusion & References)

<< Back to Programming