Writing Code That Writes Code
by Steve Marshall on Aug 06, 2009
- 3,759 views
The best developers are fundamentally very lazy. What if there was a way to write a fraction of the volume of code you currently write without losing any functionality, and massively increasing code qu...
The best developers are fundamentally very lazy. What if there was a way to write a fraction of the volume of code you currently write without losing any functionality, and massively increasing code quality (can you say '100% test coverage')?
Code generation allows us to do exactly that: we can write less code that does more. Imagine a world where all your code is unit-tested, fully documented, clearly commented, fully optimised, is a joy to maintain, and /still/ meets all the requirements. That world is exactly what code generation offers.
Why outsource code to someone halfway around the world when you can outsource it to the little goblins inside the magic box on your desk? Steve Marshall will show you the how, the why, and the 'what's that warm feeling inside?'
Accessibility
Categories
Tags
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 1
- Downloads
- 18
- Comments
- 1
- Embed Views
- Views on SlideShare
- 3,587
- Total Views
- 3,759
Abdul Qabiz
1–1 of 1 previous next
Steve Marshall
- Interested in everything
- Want to be a pirate
- Y! Ents
Why codegen
- Don’t like repetition
- Don’t like repetition
- Interesting problem of scale
- Lack of resources => be creative
Quality
Lots of code => inconsistencies
Templates => consistent quality
Consistency
- Consistent naming
- API style
- No surprises
Single Point of Knowledge
Schema describes system simply
Architecture documented, not embedded in code
Facilitates Bulk Refactoring
Faulty assumptions in hand coding mean refactoring lots of code
Generation makes refactoring minimal
Also: generation can compress project timelines => more time to design/prototype, less need to refactor
Architectural Consistency
- Generator encourages working within architecture
- “generator doesn’t do that” can indicate that the feature doesn’t fit the architecture
- Consistent, structured approach, regardless of team members joining/leaving
Abstraction
- Application logic is language-independent. Can easily port templates to other languages (eg. for performance, also: WSDL describing inputs/outputs)
- Can easily review/validate abstract designs
- Aids development of non-implementation code (tests, documentation, etc)
High Morale
Less gruntwork to do by hand
More focus on interesting problems
Higher morale
Also: higher quality, consistent code => confidence and pride
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
- Munging
- Code expansion
- Mixed codegen
- Partial class gen
- Tier gen
- FDL
Produces some non-source output
See documentation, linting, … Also: build header files, web service layers
Replaces with production code
eg. Embedding SQL in source à la Pro*C/SQLJ
Looks for specially formatted comments, fills comment-wrapped area with new production source
eg. Marshalling code
Applies def’n to templates to output base classes
Used with subclasses for custom behaviour
Can be a stepping stone to tier generation
eg. Model-driven generation takes definition file and applies to templates
Like partial class, but without special cases (or are codified in templates)
Partial class generation requires extra code, tier doesn’t (but may have it)