Code Generation in Application Development
Till date there would have been hundreds of thousands of lines of code written in each programming language. Every new application getting developed adds thousands of lines of code to this code pool. But this code is not for free, it involves huge amount of money. There are many techniques to reduce the application development cost and to improve productivity. Still we have to handwrite all the code. UML design tools, IDEs like RAD and Eclipse etc. do help in automating this code writing process. Still there is a lot of room to automate it further. The main hurdle is application architecture/framework that is specific to each application, because each application is a solution to a peculiar problem. This stops us from automating the code generation. Here is a method that will allow you to save huge amount of effort by generating code in most common as well as complex application development scenarios. I am assuming that the reader already knows application development lifecycle.
Pilot Module Implementation:
As a starting step of any project, mostly we define architecture suitable to application functional and non functional requirements. This stage also involves identification of technology suitable for the application. Subsequently, we can go into detail design and then in coding. But hold for a while here, instead of going for coding of all the components, select one or two simple but those components which span across all tiers identified in architecture. Deploy the best developers and code these modules/components. Review and ensure that these are at best of their quality. This is the starting ground for the code generation exercise, a working complete module with best quality.
Common Code Identification:
Pilot module implementation has given us good quality code of all the layers. All other modules will have similar code just that the functionality will be different, and this will involve different classes. Usually when work is assigned to developers, they end up duplicating these classes and changing them to suite new needs. From these classes, those code elements that a developer keeps intact are going to be common across all the components. We identify all such common code elements and also those that are going to change class to class.
Templates to Represent Classes:
After identification of common and uncommon code, we can generate templates. Any template technology can be used for this purpose. Each layer will have a template. Suppose we have an action class calling a business logic class, and this business logic class calling data access object class, then there will be a template for action class, one for business logic class and one for the data access object class. All these templates will have place holders which we will replace as per our module design. In addition to this we can add comments which will help developers to decide what to do next, e.g. adding some validation in action class.
Define Input to Code Generation:
Based on pilot, we have defined our templates, now we need to give input to the code generator which can be used to replace all place holder tags of our templates. This input should also include the package structure as per the architecture and layers identified. You can use xml file or an excel file as input so that it is easy for the designer to enters. Just ensure that the input file is reviewed thoroughly so that it does not result in wrong code generation which does not compile.
Generate Compiling Code:
Now we have templates ready, and input design is also ready, the next step is to generate code according to the input design. Just ensure that the code compiles properly. This code generator replaces the place holders from templates, creates classes in defined package structure. We just need to compile the entire code to ensure that everything is fine. If the generator encounters any problem then instead of doing half generation, abandon everything with proper error details.
Also, generate configuration files required in deployment. E.g. you may be using Spring to integrate classes of different layers, then generate spring context files for all required dependency injections. In addition to this you can also generate the ORM mapping files, if you are using any such tool to interact with database.
Example:
As an example, let us generate xslt based template for an action class from the Spring MVC tutorial.
HelloWorldController.java
package com.myorg.springmvctutorial.web.controller;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.servlet.ModelAndView;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@Controller
public class HelloWorldController{
protected final Log logger = LogFactory.getLog(getClass());
@RequestMapping(value="/helloWorld/{id}", method=RequestMethod.GET)
public ModelAndView helloWorld(@PathVariable String id, Model model ){
logger.info("id " + id);
return new ModelAndView("helloworld");
}
}
ActionClass.xslt
<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:fo='http://www.w3.org/1999/XSL/Format' xmlns:redirect="http://xml.apache.org/xalan/redirect" extension-element-prefixes="redirect" version="1.0">
<xsl:output method="text" encoding="ISO-8859-1"/>
<!--action Code -->
<xsl:template name="actionClass">
<xsl:param name="actionName"/>
<xsl:for-each select="myProject/record">
<xsl:if test="($actionClass=$actionClassName)">
<fo:block white-space-collapse="false" usage-context-of-suppress-at-line-break="ignore">
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.servlet.ModelAndView;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* This class is action class for ---
*
* @author
*/
public class <xsl:value-of select= "$actionClass"/>{
/**
* Logger for the class.
*/
protected final Log logger = LogFactory.getLog(getClass());
}
</fo:block>
</xsl:if>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
Points to Consider:
This code generation exercise can be more beneficial if we follow these points. Ultimate aim is to generate as much as possible code.
1. Interface and abstract class based programming
2. Not only code but configuration files also
3. Generate JUnit for trivial classes
4. Doubly ensure correctness of input design
5. Add code to source control and use it as starting point
Advantages:
Finally here is the list of all those things we achieve by this exercise. There will be clear benefits in terms of money. You can measure this by consolidating the percentage of effort getting saved in each class and calculating weighted average of all. But in all the development effort saving can be up to 40 to 50% and even more depending on complexity of business logic.
1. Effort saving, money saving
2. Improved productivity
3. Uniformity across different developers
4. Better control on code quality
Challenges:
One that I know is – it is difficult to generate jsp code cause there is little common. You can use technologies like Tiles to come over this.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.