What does refactoring mean to you?

Question

Hi, bit of a subjective question but - I'm not looking for a definition, I'm more interested in what it means to you? What does refactoring mean to you?

Answer 1

Changing code to make it more readable, reusable and maintainable.

Answer 2

Change the structure of a program without changing the functionality.

Usually it is done to improve the structure to ease maintenance or allow new features to be implemented in the next step.

Answer 3

Keeping the code clean and manageable for yourself and others.

Answer 4

According to Martin Fowler:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

For more information, check out: http://www.refactoring.com/

Answer 5

Changing the code's internals so that it is better (more readable, easier to maintain, or for whatever reason) but in a way that the code looks and works the same externally.

Answer 6

The process of improving the existing system design without changing its behavior.

• Refactoring Catalog
• Wiki pages on about Refactoring

Answer 7

Iterative improvement of your code, to positively affect readability and performance without affecting what it actually does.

Answer 8

Quite simply, if you knew then what you now, you would have designed one or more components of Application X a little differently.

Perhaps requirements have changed, perhaps *you * have changed or maybe you rushed some previous work. Regardless, there often comes a time when it is worth re-visiting sections of your code, to tweak (or perhaps completely redesign) it - with the intention of improving performance and/or maintainability.

In reality, at the end of every stage of development, I express an intention to refactor certain components in the not-too-distant future, but it doesn't always happen. Sometimes you settle for a working application rather than a 'perfect' application.

Answer 9

Improving code quality. Or more often, correcting wrong technical decision (design) taken in the past due to various reasons (lack of information, changes in the scope, lack of experience of the developers, etc.)

Answer 10

When you mess your algebra up and have to redo it.

(That's what it means to me at least, but probably isn't what you wanted :-P)

Answer 11

To answer this question I have to look at some specific cases I encountered recently and the reasons why I spent time (and hence money) refactoring. The most common one was reusability, which in turn led to portability. Basically I had a bunch of code that was Win32 specific and I wanted it to run on Windows mobile as well as Win32. The refactoring in this instance seperated and isolated all the OS specific stuff into a single file. Another one I find myself doing quite a bit is modifying similar objects such that common functionality is placed into a shared base class, where I know I will have a requirement to provide similar functionality at some stage in the future. Basically investing a small amount of time now to save a lot of time later.

So what does refactoring mean to me as a concept? Probably investing some extra time in existing code to enhance its value and/or prolong its life. IMO, for the cost/benefit of this to work, you typically need decent automated regression testing.

Answer 12

Stress testing my colleagues and the VCS without breaking the tests. **grins**

Answer 13

Stripping code down to make it as terse as possible without losing functionality or reducing efficiency. Making functions/methods as simple as they can be - often doing just one job each. Returning zero or being quiet on success. Removing bugs and edge cases. Making the code look tidier, reducing the need to comment code.

Answer 14

Improving existing code by making minor changes. Minor changes can be as simple as changing how a class is organized or creating new classes from an existing one so that each has a clearer responsibility and structure rather than overloading a class to the point of bloat.