Code generation: problem solver.
Composition, abstraction, design patterns, a walk in the park thinking of a better solution: constructive techniques.
It often tempts me to use code generation when I’m facing a problem that requires a lot of code to be written in order to solve each of it’s instances (ex: classes in the data access layer). It is the case when I’ve already used all the tools in my (small) development arsenal, and it seems I can no longer simplify and reduce the code that needs to be written by the clients of the solution. The clients being, in most cases, myself.
And the most annoying thing is that I feel there is still too much repetitive code or logic, and there must be a better way around it. But the programming language doesn’t want to help me anymore, and I can’t think of any other solution. And I try to scribble other designs, and when I think I’m onto something, and try to translate the new solution into code, there is always a catch, some missing feature of the framework library, or of the language itself, or a glitch in my logic.
And there’s the Code Generator behind me, grinning, telling me: “You know you can’t avoid me…”. But I keep on trying: “Go away, leave me alone, there must be a better solution to all this crap (that I’m mostly to blame for)!”. And he goes: “Don’t ignore me, I might be your best friend at the moment.” - “But I hate you! You are possessive, you give my code inertia, and I suffer headaches when I try to make even the smallest change.” - “Hmm, that’s an oxymoron: the best friend you hate the most. C’mon, see the bright side, your code will barely change. It will look as young as when you first wrote it, even after years of use and abuse. It will become immortal :).”
Finally I give up and I try to make up for the compromise I’m committing: “At least I will generate very beautiful code, with all the comments it needs and exception handling and bells and whistles. And there will be extension points, so I will be able to add more features to the definition, like automatic validation-based-on-some-obscure-rules-that-I-will-come–up-with…”. And I feel sad…
Well, I can’t be sad about my work. I’m still a programmer because I like programming, and I expect that software development should bring me joy and fulfillment, not frustration and sorrow. That’s the moment I start to think that if my system was built the right way, every feature should be replaceable. I don’t have to bang my head into finding a perfect solution for a functionality, that will probably be replaced in the future.
Ok, so what I really need to take care of is that the generated code is isolated enough so other parts of the system don’t have direct dependency on it, but rather on a contract the generated code implements. Maybe a smarter person will find a solution for my problem, and they usually do. At that time I’ll be able to end my unpleasant relation with the code generator, and look behind and smile.
Resources
http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell