Code generation comes in many forms, shapes, and formats. Most of us already use code generation, often daily. Code is generated whenever you type “dotnet new …” or “ng generate …” or many other command-line tools. Or when Entity Framework requests data from a database, a SQL query is generated and then executed. Some code is generated at design time, some at compile-time, some at run time, and in the end, it’s all code generation.
However, I use the term code generation to represent something more. Maybe it’s something else, and I haven’t found the right name for it? I use code generation in all its other forms every day; it’s just a part of my workflow. But, when I think Code Generation, with a capital C and G, it’s bigger than that.
Where did this come from?
While I did write code generating code way before that, I started actively pursuing this when I discovered the Visual Studio Modeling SDK. That was in the early 2000s (2003, I think). The SDK introduced me to the concept of Domain Specific Language (DSL) and many of the tools required to support it. Right there and then, I knew what I wanted to do…
I wanted to generate entire systems. Especially the more tedious parts of it. At the very least, I should be able to create complete sub-systems.
Now that is generating code at a different scale!
Scaling code generation
The challenge was that to generate code to that scale, I needed to generate a wide variety of code that served different purposes. It’s not all repeating the same thing over and over.
As an example, I need to create code to build data structures, but I need to:
- Validate that data;
- handle its states;
- write it to, and read it from a persistent store;
- display it on screen;
But then, maybe I could also generate the different tiers, database, web services, and application tiers. (early 2000, remember 🙂 ). So I needed to generate a lot of code for different languages and technologies too:
- Data Definition Language (DDL)
- Structured Query Language (SQL)
- ADO .Net code, POCOs, interfaces, in C#
- Aspx pages (aspx)
- Project files (XML)
- and more…
In addition, I needed the process to be:
- Repeatable: The process can be used multiple times, and given the same inputs, the result should always be the same.
- Predictable: The system user should be able to predict the results based on the input given.
- Flexible: The system should be extendable and modifiable to support a wide variety of different requirements,
To achieve this, I needed 3 things:
- Model: A set of data that describe the behavior or functionality that I want.
- Solution: A set of instructions that process the Model to turn it into code.
- Result: The output is code that I can use, review, compile, and execute.
So I set out on this journey to create what I called Software Factory for the lack of a better name. I’ve spent countless hours since then working on this.
And, you know what? It works!!!
I’m currently working on the fourth version of it. Actually, 75% of version 4.0 is generated using the previous version.
This workflow changed how I write code, and its event changed my vision of software.
It’s a bit crazy, I agree! But, in the end, it’s all about the outcome: Generating entire systems with the click of a button! I’ve written millions of lines of code, so I don’t have to write code anymore.