An example of preparatory refactoring

martinfowler.com

35 pointsandima3 comments

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.

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

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.

Reply on news.ycombinator.com