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.

EditText of this page (last edited May 13, 2005)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006