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?
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.
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.
We do three separate things in our company, with allocated time for the three:
Example: splitting an ugly and unreadable 100 lines method which does four things into four reusable methods, 25 lines each.
Example: removing commented code after ensuring that this code is not needed anymore.
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.
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.
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.
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.
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.