C ODE GENERATION CONCERNS

No technique is without drawbacks, and code generation is no different. In the follow-ing sections, we describe some of the issues you may encounter when proposfollow-ing, build-ing, and deploying code generators.

Some of these are fear of the unknown, others are an unwillingness to change, and still others are well-founded technical concerns. All of these issues will need to be addressed at some level and at some time during the deployment of a generator. We list them here to help you with some counterpoints to the criticism.

Figure 2.9

The coding workflow when a code generator is involved

2.3.1 Nobody on my team will accept a generator

Creating a tool that builds in minutes what would take months to write by hand will have a dramatic effect on the development team, particularly if no one on the team has experience with automatic code generation. With a small engineering team or one that has had generator experience, there probably won’t be any reticence toward adopting generation. With larger teams you may experience problems. Some engineers may dig in their heels and swear that they won’t use generators; they may try to influence other team members as well. Here are suggestions for handling these problems:

• Start small—Take a small section of the code base that requires maintenance and replace it with a generated version. Ideally, this will be a section of code that could become larger over time so that the investment in building the generator has a high payoff. Start with a small section of code so that engineers and management can see how code generation works and understand the benefits for the organization.

• Integrate with the architecture—When building a new generator, people often sug-gest changing the architecture of the application in conjunction with building the generator. The idea is to kill two birds with one stone. The first goal is to fix the architecture and the second is to speed up the development process. These find-ings are welcome of course, but coding more quickly and changing to a better architecture are two separate issues. Our recommendation for your first code gen-eration project is to tackle building code in the existing framework. Once you’ve finished the generator and tested and stabilized the output code, you can alter the templates to move to a new architectural model.

• Solve one problem—The ideal generator can solve a number of problems in the architecture and the implementation of a product, as well as accelerate the sched-ule. If this is the first generator going into a project, you should concentrate on the schedule issue alone. Taking on several tasks in the first release of a generator can open up too many issues at once and muddle the decision making. You should focus your effort on solving one or two key problems.

2.3.2 Engineers will ignore the “do not edit” comments

One of the most common problems with a generated code base is that engineers will ignore the plentiful warnings in the comments of the file indicating that the code should not be edited.

I can’t stress enough that your first reaction to someone breaking the “do not edit”

rule should be sympathy. Engineers break the rule because they want to get something done and either they don’t understand how to run the generator or the generator sim-ply could not do what they needed. In both cases, you need to educate your team and perhaps alter the function of the generator to address their reasons for ignoring the comments. The important thing is not the infraction, but the fact that a team member

CODEGENERATIONCONCERNS 37 was using the code and possibly using the generator—which is a great starting point for the deployment of the generator.

If engineers continue to violate the “do not edit” rule, you may need to go back to the drawing board with the generator, the deployment, or both. Engineers who are conscious of the value of the generator and who understand how the generator works should not alter the output by hand and expect that their changes will be maintained.

2.3.3 If the generator can’t build it, the feature will take weeks to build

Suppose you’ve developed a generator for a user interface builds assembly code from a set of high-level UI definitions. It builds everything: the window drawing code, the message handling, the button drawing—everything, right down to the machine code.

What happens when you need to add a dialog box to your UI that cannot be built with this generator? In the worst-case scenario, you get out your assembly language manual and go for it.

This is an unrealistic and extreme example, but it proves the point that you always want your generator building code that sits on a powerful framework. An example is the Qt cross-platform UI toolkit. Figure 2.10 shows a generator for Qt code.

Should a generator replace the functionality of Qt? No. It should generate code for Qt from high-level UI definitions: the same high-level UI definitions that can be used to build the web interfaces that Qt can’t build. There is also nothing wrong with hav-ing the generator write code that makes use of your own libraries, which sit on top of powerful frameworks.

As with any software engineering project, you will want to spend the time picking an appropriate and powerful architecture and development environment.

Using code generation techniques in combination with the right development tools can significantly enhance the quality and reduce the development time of your appli-cation development.

Figure 2.10 Generating code for the Qt framework

Figure 2.11 shows a generator that builds to both Qt and a company-specific interface library. Including code to manage the interface can make the generator run more smoothly, as well as make it much easier for an implementer to build the dialog boxes that cannot be created by the generator.