topics/softwareDevelopment/refactoring/introToRefactoring.txt

P. Conrad  for CISC474, 01/06/2006


What is "refactoring"?
======================

If you read the latest writing on software development, especially things
coming from folks who use words like "agile", "eXtreme Programming", etc.,
you'll hear the word "refactoring" used a lot.

Some tools, such as Eclipse, give you "support for refactoring".

Typically, these folks assume you know what they mean by "refactoring".

This is _not_ a word that was used when I learned how to program, so I
decided to try to find out where it came from, and what these folks
mean by that word. 

I had a sense that there was a lot of "meaning" wrapped up in those
four little syllables.

This was confirmed when I found a 464 page book on the subject:

 Refactoring: Improving the Design of Existing Code
  By Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
  Addison Wesley Professional, 1999, ISBN: 0-201-48567-2.

This seems to be one of the first books on the subject (another being the one
on "Anti-Patterns" listed later in this file).


Here is what this book (Fowler, et al.) says about refactoring:

What Is Refactoring?

 Refactoring is the process of changing a software system in such a
 way that it does not alter the external behavior of the code yet
 improves its internal structure. It is a disciplined way to clean up
 code that minimizes the chances of introducing bugs. In essence when
 you refactor you are improving the design of the code after it has
 been written.

 "Improving the design after it has been written." That's an odd turn
 of phrase. In our current understanding of software development we
 believe that we design and then we code. A good design comes first,
 and the coding comes second. Over time the code will be modified, and
 the integrity of the system, its structure according to that design,
 gradually fades. The code slowly sinks from engineering to hacking.

 Refactoring is the opposite of this practice. With refactoring you
 can take a bad design, chaos even, and rework it into well-designed
 code. Each step is simple, even simplistic. You move a field from one
 class to another, pull some code out of a method to make into its own
 method, and push some code up or down a hierarchy. Yet the cumulative
 effect of these small changes can radically improve the design. It is
 the exact reverse of the normal notion of software decay.

 With refactoring you find the balance of work changes. You find that
 design, rather than occurring all up front, occurs continuously
 during development. You learn from building the system how to improve
 the design. The resulting interaction leads to a program with a
 design that stays good as development continues.



Another book on Refactoring with an earlier publication date:

 W. J. Brown, R. C. Malveau, H.W. McCormick, T. J. Mowbray,
 AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis 
 Wiley, 1998, 336 pages. ISBN: 0471197130

 http://www.amazon.com/gp/product/0471197130/qid=1136575311/sr=1-6/ref=sr_1_6/103-1657617-5115009?s=books&v=glance&n=283155