Refactoring Writ Large

From AOCWiki

The purpose of this session was to explore possible links between the following phenomena:

• Don't Repeat Yourself in Rails: the structure of your database automatically (and dynamically) generates appropriate methods in your classes.
• Code Generation tools; see, e.g., the book Code Generation in Action by Herrington.
• The current popularity of DSLs (domain-specific languages).
• Tools that are created for non-developers to use, that end up speeding up the work of professional developers. (See this discussion of how the user-generated content creation tools allowed the LittleBigPlanet level designers to work in a more agile fashion.)

To me (the convener of the session, David Carlton) , these examples suggest that we should look at the concept of refactoring more broadly than it's presented in, say, Fowler's book: refactoring can be at its most powerful when it leaves the confine of your initial implementation language.

Some thoughts we had:

• LISP macros are an interesting example: they're much more powerful than macro approaches in most other languages.
• Think about this from a QA point of view: write code/tools/... to make it easy for them.
• On the topic of DSLs:
  • A DSL should solve some specific problem.
  • If an operation is common, with one best way to perform it, make sure your language makes it trivial to get that right. (Changing implementation languages if necessary!)
  • Leverage a convention-based approach: at the least, you should have useful defaults, ask yourself the question of how much configuration you should allow beyond that.
• If you're crossing languages, you'll have a higher learning curve. Or: increased maintainability suggests fewer languages.
• On parsing DSLs versus interpreting them directly:
  • The latter is often easy in a scripting language.
  • antlr was mentioned as a parser generator.
  • Lots of tools for parsing XML.
  • LISP!
• If you're generating code:
  • DON'T MODIFY GENERATED FILES!
  • Don't generate big, bad code.
• When developing tools for non-developers, watch what they actually do / need, and make that simple. (See the discussion on conventions above.)