|< Day Day Up >|| |
Like many other things in software development, code generation is a bit of a balancing act: there are good reasons to use it, but there are also good reasons to avoid it. Ultimately, you need to decide on a case-by-case basis whether code generation makes sense for individual projects. That said, I can provide some general guidelines.
The list of reasons not to use code generation starts with vendor worries. If you choose to let your project depend on a tool from an independent software vendor, then you need to take into account what might happen if the vendor goes out of business or fails to support its product. At the very least, you should have a backup plan: Can you simply continue to use the already-generated code, even if you have to abandon the tool? If not, how long will it take to replace it with other code, whether from another tool or written by hand? Another way to avoid this problem is to write your own code-generation tools. That can be an attractive alternative if your team is large enough to support a dedicated toolsmith, but it’s less feasible for a small team or a lone wolf developer.
You also need to worry about the quality of the generated code. It probably won’t be exactly the code that you would have written yourself, which may be a good thing or a bad thing depending on your own level of experience. But if you have to go into the code and fix it, it’s useful to understand what’s going on. Comments and documentation are your friends here. Products that let you edit a template to customize the generated code (as opposed to those that lock everything up in compiled logic) have an advantage here.
Also, beware: With many code-generation products, any fixes you make will vanish if you need to regenerate the code later on. This makes it more important to focus on products that generate the code you want the first time, or that let you edit the template rather than the generated code.
Here’s a final cautionary note: You need to realize that these tools don’t quite provide something for nothing. Depending on the complexity of the tool, a substantial learning curve may be involved in using it effectively. You should use the tool often enough that the time spent learning it is outweighed by the time it saves. Otherwise, why bother?
On the positive side, saving labor is usually the most attractive reason for adopting a code-generation tool. If you’re faced with writing wrapper classes for a thousand database tables, for example, it’s difficult to imagine that you’d spend less time doing it by hand than you would learning to use a tool for the same purpose. And the more projects you use the tool with, the more savings it can deliver for the same amount of effort.
Equally important as a reason to use these tools is the impact of code generation on the quality of the final code. If you use it right, code generation can help prevent errors that might otherwise creep into your source code. The Downloads.cs class, for example, includes over 1500 lines of code and comments. How many mistakes might I have made writing that by hand? Instead, by using a thoroughly debugged template together with a code-generation tool, I can have high confidence in the mechanics of the collection class.
|< Day Day Up >|| |