Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

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

15 Answers 15

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.

share|improve this answer
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!) –  Frank Shearar Mar 25 '11 at 13:50
add comment

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.

share|improve this answer
    
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. –  Frank Shearar Mar 25 '11 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 Mar 25 '11 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. –  Chuck Stephanski Mar 25 '11 at 18:06
    
Indeed, I mentioned that it was new jargon... relative to the lambda calculus. –  Frank Shearar Mar 25 '11 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 Mar 28 '11 at 21:11
add comment

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.

share|improve this answer
2  
+1 on making clear distinction –  Aditya P Mar 25 '11 at 10:12
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 Mar 25 '11 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 Mar 25 '11 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. –  JBRWilkinson Mar 25 '11 at 17:15
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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 Mar 25 '11 at 13:26
    
@user21007: Code is a lot more complicated than a database schema, but a lot easier to change and deploy. –  kevin cline Nov 23 '11 at 14:28
add comment

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.

share|improve this answer
add comment

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 :)

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
renaming is a standard refactoring technique! –  Chuck Stephanski Mar 25 '11 at 18:01
add comment

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

share|improve this answer
add comment

No. Refactoring is improving structure without changing behavior. Refactoring in the strict sense entails good test discipline. That's not necessarily required when you "clean things up".

share|improve this answer
1  
dangerous attitude. Removing a whole swath of dead code and dead configuration is cleaning up and changing the signature of a single method a refactor. Yet in both case I would want to get a good test discipline to ensure that I did not break anything. –  Newtopian Mar 25 '11 at 10:42
    
I'm not saying that it's a good/safe/desirable to make major changes without test discipline. I'm saying that refactoring as a methodology involves test discipline, whereas "cleaning things up" isn't a methodology at all. –  Willie Wheeler Mar 30 '11 at 5:58
    
So if I understand correctly if it does not have a proper fancy name then we are good to go !! :-O just kidding, I see what you are trying to say, true that cleaning things up could hardly be called a methodology but then again neither is refactoring. It's just a fancy word that states you are changing the code without altering it`s behaviour. It has, by itself, no implication on testing whatsoever. Following good coding practice will state that if the code changed then it should be tested regardless on how you call the action that generated the change. –  Newtopian Mar 30 '11 at 7:38
1  
Sure, I can buy that. Test discipline is more about how one goes about performing the refactoring, but it isn't inherent in the definition. (I.e. I can refactor code without any tests at all.) I don't know if I can agree that refactoring isn't a methodology--there are whole books written with step-by-step patterns and so forth. –  Willie Wheeler Mar 30 '11 at 7:44
add comment

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.

share|improve this answer
    
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 Mar 25 '11 at 11:50
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

"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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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