

An example of preparatory refactoring - andima
http://martinfowler.com/articles/preparatory-refactoring-example.html

======
logn
This article is long and confusing for me. However, the sidebar emphasized his
important point here about "adding function" vs "refactoring" \-- _The adding
function hat is more stressful and riskier, so it 's nice to wear the
refactoring hat as much as possible._

What I take away is that if you refactor before adding new functionality, the
refactoring is a lot easier because you can test that the functionality
doesn't change at all. If you refactor after you add new functionality, you
have to test all at once that there are no regressions and that the new
functionality works, so the refactoring becomes as stressful as adding new
functionality.

------
btbuildem
TL;DR: Plan what you're going to do.

~~~
dangoor
I don't think that's the main point. The main point is to use the approach
"make it easy to make the change you want to make, then make the change" and
this article is a concrete example of how Martin did that in one instance.

