Goals of refactoring?

Question

What are the goals of refactoring code? Is it only to enhance the code structure? Is it to pave the way for future changes?

Answer 1

• reducing complexity of individual functions - makes testing easier
• eliminating repeated code - reduces opportunities for mistakes

Answer 2

1. To eliminate/reduce the "Code Smells"
2. Easier for any developer to understand the code
3. To make it maintainable.
4. To increase cohesion and to reduce coupling"

Answer 3

I don't usually refactor code just to reduce code smells, or make it 'nicer'/more maintainable. I do refactor, when I need to fix bug, and I want to leave code in better shape than it was before. Other reason is when I want to add functionality, and it would be hard to do without refactoring. Third reason is to make code more testable. Sometimes I refactor to learn the code which I don't understand :-)

Answer 4

On a very basic level the goal is to improve the code, making it more readable, less coupled, decreasing error rates, and so on.

On another level refactoring came about as an alternative to BigUpfrontDesign. Also when used in contexts such as Extreme Programming refactoring is a duty. You pay mortgage on your technical depts every day, every hour. Together with principles as Collective Code Ownership it also makes each individual responsible for refactoring code anywhere, not just the code written (or co-written) by oneself.

Answer 5

Refactoring can have multiples incentives:

• improve code readability
• simplify code structure
• improve maintainability
• improve extensibility

The reason to start refactoring usually depends on the problems you ran into.

If you extend your software and stumble across bugs and you can't find the origin of the bugs, then you might start refactoring to simplify the code structure in order to make it easier for developers to track down bugs.

Sometimes bugs come from a function/class/... that was used not like it was intended. This indicates that the code was not easy to understand or badly documented.

Now, if you improve the documentation, the readability of the code and the structure of the code you will also yield a better maintainability...

Answer 6

Of course, when you are sure that you will never ever have to touch a piece of code again, there's no need to refactor that code.

But most of the time, you will have to touch it again because you will have to add features, fix bugs or optimize it.

So, yes of course it is to pave the way for future changes. Code always changes.

Answer 7

Understandability

More straightforward and well organized (factored) code is easier to understand.

Correctness

It's easier to identify defects by inspection in code that's easier to understand. Overly complex, poorly structured, Rube Goldberg style code is much more difficult to inspect for defects. Additionally, well componentized code with high coherency of components and loose coupling between components is vastly easier to put under test. Moreover, smaller, well-formed bits under test makes for less overlap in code coverage between test cases which makes for faster and more trustworthy tests (which becomes a self-reinforcing cycle driving toward better and better tests). As well, more straightforward code tends to be more predictable and reliable.

Ease of Maintenance and Evolution

Well-factored, high quality, easy to understand common components are easier to use, extend, and maintain. Many changes to the system are now easier to make because they have smaller impact and it's more obvious how to make the appropriate changes.

---

Refactoring code does have merit on its own just in terms of code quality and correctness issues, but where refactoring pays off the most is in maintenance and evolution of the design of the software. Often a good tactic when adding new features to old, poorly factored code is to refactor the target code then add the new feature. This often will take less development effort than trying to add the new feature without refactoring and it's a handy way to improve the quality of the code base without undertaking a lot of "pie in the sky" hypothetical advantage refactoring / redesign work that's hard to justify to management.

Answer 8

Code refactoring is a necessity of observing the fact that change is inevitable. It's principal goal is to enhance the current code or design in order to make it amenable and congruent with new functional or non-functional requirements or to make it more tolerant to change.

Examples of scenarios where refactoring may be necessary:

1. Introduction of a new business rule that requires the current design to be abstracted to a new level;
2. Recognition of the fact that the current design could be modified in order to better observe the SOLID principals of object-oriented design;
3. When code testability needs to be increased---this relates to 2 above.

Answer 9

Refactoring is used to pay your Technical Debt.

Answer 10

To reduce the cost of change.

Answer 11

Generally speaking, I'd only refactor production code to reuse it or when modifications are required.

For example, I needed to update a function for performance reasons, but there wasn't an easy test interface, so I refactored it into a separate module which could be unit-tested more easily, then made the changes so I could re-run the tests and show that it worked as before.

Refactoring code which does not need to be changed is a recipe for disaster; it's guaranteed to introduce bugs.

Answer 12

Goals of refactoring?

Passtime?

Seriously, I do it to:

• avoid code duplication when I see it (following DRY principle)
• simplify the code (remove unnecessary ad-hoc complexities, see KISS)
• remove old/stale/deprecated code (cleaning waste, once the old code is replaced)
• eliminate side effects
• generalize and reuse existing code

Answer 13

Organization.

Answer 14

To me: Performance.

Answer 15

In short... To de-stinkify the code.