Refactoring Language

MartinFowler's book RefactoringImprovingTheDesignOfExistingCode may do for refactoring what DesignPatterns did for design: create a language (a system of words) that we can use to express our refactoring thoughts.

The catalog from the book, with additions, is at

Organizing Classes: Composing Methods: Within Methods: Organizing Data: Making Method Calls Simpler: Dealing With Generalization: MetaRefactoring: BigRefactorings: (originally described by MartinFowler) RefactoringLegacyCode: JavaLanguage Specific: (RefactoringIdioms?) AspectOrientedRefactoring:

Of course, if you want to see the real dictionary for this language, go buy the book: RefactoringImprovingTheDesignOfExistingCode.

Hear, hear. I've just finished reading the essay-type sections, and I now don't want to design my next application, but instead let the design evolve from the code. Unfortunately, my manager is one of the lots-of-upfront-design types. Oh well, maybe we can strike a compromise in the middle.

Easy: Ensure that you have plenty of unit tests. If the design isn't testable, then file a bug against it (BDUF people probably don't like the idea of untestable things, so they'll fix it). In 6 months time, when the design is hopelessly out of date, you'll have a good case for refactoring: Anyone counting beans will see the cost advantage at that point.


View edit of February 12, 2009 or FindPage with title or text search