Before Martin Fowler's book "Refactoring: Improving the Design of Existing Code" came out, we used to call major changes to code "rearchitecture" and minor changes "cleanup". IMO, refactoring techniques are all common sense / obvious things we've been doing forever.

Do you think refactoring was ever anything new? Perhaps just a way to trick management into allocating time for code cleanup?

  • When you say "before the book came out", I presume you are referring to Martin Folwer's book is this correct?
    – AlexC
    Commented Mar 25, 2011 at 11:12
  • -1: What is the usefulness of this question?
    – Jim G.
    Commented Mar 25, 2011 at 16:47
  • Yes Fowler's book. Commented Mar 25, 2011 at 17:52

14 Answers 14


Refactoring's older than the hills, so no, it's not anything new.

And refactoring's not cleaning up. Well, it can be, but it's not limited to cleaning up.

It's adjusting the architecture of your application (whether at large or small scales) while preserving behaviour.

That means that while some part of your application might have been perfectly clean and fine yesterday, today's new feature requires adjusting that part to accomodate the new feature.

You don't want to break existing functionality, so you adjust the structure of your application while preserving behaviour - which is refactoring.

This said no matter what changes are made to the code one should always run his tests... just in case.

  • 1
    Newtopian: that's a vital point. If you haven't run your tests you have no idea whether you randomly hacked something, or actually refactored. (And of course, you need an adequate test suite!) Commented Mar 25, 2011 at 13:50

It's just tidying code up. Essentially, programmers (especially Martin Fowler) noticed that they tended to perform the same tasks each time they tidied up their code. They defined and labelled the tidying methods and associated code problems and presto! Refactoring was born.

It's the same with design patterns - people noticed that they tended to use the same approaches to particular problems over and over again. They labelled and defined the approaches and now it seems that you're not a real programmer unless you only ever use the same dozen or so patterns in your code.

There's no magic to refactoring; it's just a new set of jargon to describe an old practice.

  • William Opdyke, 1992: Refactoring Object-Oriented Frameworks. Fowler & Beck & friends popularised refactoring. Jon Brant and Don Roberts implemented the first automated tool some time before 1999. So "new set of jargon" isn't very accurate. Commented Mar 25, 2011 at 14:07
  • If you accept that computer programming has been going on since Ada Lovelace in the mid 1800s, then yes - it is a relatively new set of jargon.
    – Ant
    Commented Mar 25, 2011 at 17:35
  • 1
    I think the difference is with Design Patterns almost every developer learned some new patterns and hence some new tools of the trade from the book. With Refactoring I don't feel like anyone really learned anything. There's secondary value in just putting a name to something (and the design patterns comparison holds up there) but he could have done that w/ a blog post. Commented Mar 25, 2011 at 18:06
  • Indeed, I mentioned that it was new jargon... relative to the lambda calculus. Commented Mar 25, 2011 at 20:49
  • @Chuck, have you read the book, Refactoring? If so, I would be very surprised if you didn't learn something new from it.
    – Marcie
    Commented Mar 28, 2011 at 21:11

We do three separate things in our company, with allocated time for the three:

  • Refactoring: consists in changing the code structure, thus keeping the behavior.

Example: splitting an ugly and unreadable 100 lines method which does four things into four reusable methods, 25 lines each.

  • Cleanup: consists in doing minor modifications to make code more readable without modifying neither its behavior, nor its structure.

Example: removing commented code after ensuring that this code is not needed anymore.

  • Enforcing StyleCop/FxCop rules: consists in checking if the code matches the default set of StyleCop or FxCop rules, and if not, modify it to match those rules.

Example: adding Culture.Invariant in string.Format (or another culture which is more appropriate).

So in my case, refactoring is something very different from cleanup. When doing cleanup, I don't have to run unit tests again: if the code worked before, it will work after cleanup. In other words, it's not because I removed an empty line or added a comment that the code will stop working. On the other hand, when I refactor complicated parts of an old code, I can do some mistakes, so I must run unit tests after refactoring.

  • 4
    Although I agree that there is a fundamental difference between clean-up and re factoring there are many cases where this line blurs quite a bit. Removing a dead class and "cleaning-up" all references to it from method signatures or remaining associations would be considered cleaning or refactoring ? I also strongly disagree that running unit tests is optional. You have no idea how things could break. I have seen changes in the message string of an exception break code because someone thought it was a good idea to parse it to act on some errors.
    – Newtopian
    Commented Mar 25, 2011 at 10:37
  • I have to agree with Newtopian, particularly about not having to re-run tests. In fact, there should be an automated test suite that runs no less often than once per commit. Regardless of whether it's cleanup or refactoring, if you have a code change to commit to version control, the tests should run.
    – kojiro
    Commented Mar 25, 2011 at 14:03
  • You should always do a full build after doing any cleanup - even if it's just white-space and comments changes. Ask any Python or Makefile authors about that. Commented Mar 25, 2011 at 17:15

Refactoring adds knowledge to your code. If you know something is incorrectly named, you give it a better name. If you know something can be done better, you change it into something better.

It is a lot of steps - small and big - that hopefully result in a better program.


I agree with "refactoring is a fancy word for clean up your code" but not with "just". People use fancy words for a reason: sometimes because they want to look clever, and sometimes because they're conveying a greater or more precise meaning, and IMHO refactoring (even if occasionally misused) is generally referring to the latter.

"Clean up" could mean anything from "reformatting a bit" to "rewriting large chunks".

"Refactoring" means specifically something like "small incremental changes to the code, designed to maintain the same functionality, while transforming it into a better design". And there's a body of best practice on the sort of things you do: some is ad-hoc, but there are general principles, like using unit tests, extracting part of functions into new functions or classes, etc, which people can and should learn.

You say "just trick management into allocating time for code clean up". But if saying "refactoring" correctly conveys the concept that a steady investment in clarity now will pay dividends in efficiency in the future, then that's not a "trick", that's clear and effective communication.


Refactoring is to code as Normalisation is to relational data. It's a process of abstracting concepts into cleaner, clearer and more efficient representations of their role in the application.

  • 1
    That's an interesting way to look at it. Maybe it comes from my database background, but there is something that irks me about the stress on refactoring, and you've helped me put my finger on it. It's that in a database what you don't fix in design takes 10x longer to fix in testing and probably 1000x longer in production. So a good DBA is anal about getting things right in as early a stage as possible. My gut feeling is that too much time refactoring at later stages is indicative of too little time spent designing.
    – user21007
    Commented Mar 25, 2011 at 13:26
  • @user21007: Code is a lot more complicated than a database schema, but a lot easier to change and deploy. Commented Nov 23, 2011 at 14:28

It depends how you understand term refactoring. For most of people this is a process of improving structure without changing behaviour. If you agree, then yes it was done long before this book came out. I know, because I was (among many other things) renaming classes, extracting classes and extracting methods before the book was written. I wasn't calling it refactoring, but in essence I was doing exactly the same thing.

For me personally refactoring is what people now call "automated code refactoring" ie: support for various refactoring techniques inside an IDE. This is a real improvement to what I was doing before (which indeed was very painfull). I can carry out a change in one class and not worry how this is going to affect the rest of the software. I think that Martin formalized refactoring techniquest up to the point where it could be represented as algorithm and thus implemented in various IDEs out there.

So if you understand refactoring as a process, then it is nothing new. If you see it as automation, then yes it is huge improvement. Try renaming few core classes (literally, not through refactoring options of your IDE) in a reasonably large project to see why :)


Refactoring is indeed code "cleanup", but also restructuring the code. In my team refactoring is usually the latter. When we have a "refactor" case we allocate time to restructure our code, e.g. to make it aligned with a new architecture, or information model, or to make it more efficient.

Code "cleanup" is something that we do continously without specially allocated time for it. For me "cleanup" is usually renaming, cleaning out comments, etc.

  • 1
    renaming is a standard refactoring technique! Commented Mar 25, 2011 at 18:01

I'd say No.

There may be cleanup in the refactoring process but it is not the essence.

Cleanup comes with the assumption that the previous code is not clean. In reality, developers refactor their code even the original code is already clean.

DRY is a key drive behind refactoring.

When adding new codes to an existing code base, refactoring is done naturally due to DRY principle.

Just my 0.02


Cleaning your code is like tidying up your house, refactoring is like tearing down a wall and possibly putting it up somewhere else


When someone else cleans up your house, you can't find anything because the goal is getting things clean and out of the way. Refactoring would build and label rooms, closets, cabinets, shelves, bins, etc. It still holds most of the same stuff (you can still make a grilled cheese sandwich in the kitchen and eat it in the living room), but should make it easier to find and possibly have efficient places to put new things.

  • I'm no buzzword fanatic, but sometimes common tasks need to be labeled and formalized so everyone knows what you're talking about. A client reports a bug and the manager screams, "Go clean your code!" you know they aren't talking about refactoring.
    – JeffO
    Commented Mar 25, 2011 at 11:50

The term 'refactoring' is elegantly borrowed from algebra. It means simplifying the terms to produce the same result. Not only elegant, it was revolutionary -- it required a hard finite approach to your code, at a level that surprised many. And so the term itself was significant and helpful.


The two overlap a bit at the edges, but to me it's the difference between cleaning the house and remodeling the house. Cleanup, to me, does not imply structural changes, while refactoring does.


"Refactoring" is really the same thing as "rearchitecture", but with a stronger connotation of "no functionality changes". It's also clearer in terms of the goal of re-architecture, which is often to "factor out" common code into reusable chunks.

Not the answer you're looking for? Browse other questions tagged or ask your own question.