Refactoring code is a process of cleaning up your code, reducing the clutter and improving the readability without causing any side effects or changes to features.

Basically, you refactor by applying a series of code change rules that improve code readability and re-usability, without affecting the logic.

Always unit test before and after refactoring to ensure your logic isn t affected.

This Wikipedia article will give you an idea of the types of things included in the general concept of Refactoring.

The idea is adapt / evolve your code as you go. Simple things may be to rename variables or method parameters, but others may be to pass an additional parameter or to drop one, or to change its type. The data model may evolve as well. etc.

Often refactoring, works hand-in-hand with unit-testing, whereby the risk of "breaking something" is offset by the fact that such an issue may likely be discovered by the automatic testing (provide a good coverage and relevant test cases...).

In a nutshell, the ability to refactor (and btw, most IDE or add-ons to the IDEs, offer various tools that make refactoring easier and less error prone) allows one to write more quickly without stressing about some decisions ("should this object include an array or a list etc...) letting the programmer change some of these decisions as times goes, and with the added insight offered by having a workable, if not perfect solution. See a related concept: agile development.

Beware, refactoring doesn t give you license to start coding without putting any thought in design, in the object model, the APIs etc., however it lessens the stiffness of some of these decisions.

Martin Fowler has probably done the most to popularize refactoring, but I think good developers have always done these sorts of restructurings. Check out Fowler srefactoring web site, and his 1999 Refactoring, which is an excellent introduction and catalog of specific refactorings using Java.

And I see he s a co-author of the brand new Refactoring, Ruby Edition, which should be a great resource.

I find that regularly cleaning up your code like this makes it a lot clearer and more maintainable.

To take one example, I wrote a small (Java 1.6) client library for accessing remote web services (using the REST architectural style). The bulk of this library is in one source file, and about half of that deals with the web services, while the other half is a simple in-memory cache of the responses (for performance). Over time both halves have grown in functionality, to the point where the source file was getting too complex. So today I used Fowler s "Extract Class" refactoring to move the cache logic into a new class. Before that I had to do some "Extract Methods" to isolate the caching logic. Along the way I did a few "Rename Methods" and an "Introduce Explaining Variable".

As other folks have noted, it s very important to have a good set of unit tests to apply after you make each change. They help ensure that you re not introducing new bugs, among other good things.

In a nutshell, refactoring means improving the design and/or implementation of software, usually without changing its behavior. This is normally done to make the code easier to understand and work with going forward, thereby making future development faster and less bug-prone.

Refactoring is a long-term investment in your code - since it doesn t affect the outward "appearance" of the software, there is very often pressure (from management, etc.) to "just get it working and move on to the next thing." While this may sometimes be the right decision, depending on business drivers, a codebase that undergoes change but never gets refactored will decay into a difficult, buggy mess (See also Technical Debt).

Specifically, the top reasons to refactor are usually the following:

1. Getting rid of duplicated code
2. Breaking up a long method into smaller pieces by extracting new methods from sections of the longer method
3. Breaking up a class that has too many responsibilities into smaller, more targeted classes or subclasses
4. Moving methods from one class to another. Often this is done so the methods reside in the same class as the data they operate on.

In the simplest terms, refactoring code is optimizing code. The criteria for what is "better" code is open to much interpretation as there are various coding styles and patterns out there. A central idea with refactoring is the question of, "Could this code be made better?" A few examples of that criteria can include scalability, maintainability, readablity, performance, size of executable, or minimizing memory used in executing the code.

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." -- MartinFowler in RefactoringImprovingTheDesignOfExistingCode

see this WhatIsRefactoring for more explanation.

Refactoring code generally means taking code that has been patched multiple times and re-writing it so that the needs of the later patches are taken into account.