Refactoring

Marting Fowler Definition: Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors.

The main purpose of refactoring is to fight technical debt. It transforms a mess into clean code and simple design. Clean code:

• Is obvious for other programmers.
• Doesn’t contain duplication.
• Contains a minimal number of classes and other moving parts.
• Passes all tests.
• Is easier and cheaper to maintain!
• Should be pleasing to read

Technical debt

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Causes:

• Business pressure
• Lack of understanding of the consequences of technical debt
• Lack of tests
• Lack of documentation
• Lack of interaction between team members
• Long-term simultaneous development in several branches
• Delayed refactoring
• Lack of compliance (cumplimiento) monitoring
• Incompetence

When to refactor

• Rule of Three
• When adding a feature
• When fixing a bug
• During a code review

• How to refactor

• The code should become cleaner.
• New functionality shouldn’t be created during refactoring.
• All existing tests must pass after refactoring.

Code smells

• Bloaters (bloated: hinzadón): methods and classes that have increased the big that they are hard to work with. Long Method, large class, primitive obsession, long parameter list
• Object-oriented abusers: Alternative classes with different interfaces, refused request, switch statements, temporary field
• Change preventers (if you need to change something in one place in your code, you have to make many changes in other places too): Divergent Change parallel inheritance hierarchies, shotgun surgery
• Dispensables (something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand): Comments, duplicate code, data class, dead code, lazy class, speculative generality
• Couplers: Feature envy, inappropriate intimacy, incomplete library class, message chains, middle man

Refactoring Techniques

• Composing Methods Much of refactoring is devoted to correctly composing methods. In most cases, excessively long methods are the root of all evil. The vagaries of code inside these methods conceal the execution logic and make the method extremely hard to understand – and even harder to change The refactoring techniques in this group streamline methods, remove code duplication, and pave the way for future improvements.

• Moving Features between Objects Even if you have distributed functionality among different classes in a less-than-perfect way, there is still hope. These refactoring techniques show how to safely move functionality between classes, create new classes, and hide implementation details from public access.

• Organizing Data These refactoring techniques help with data handling, replacing primitives with rich class functionality. Another important result is untangling of class associations, which makes classes more portable and reusable.

• Simplifying Conditional Expressions Conditionals tend to get more and more complicated in their logic over time, and there are yet more techniques to combat this as well.

• Simplifying Method Calls These techniques make method calls simpler and easier to understand. This, in turn, simplifies the interfaces for interaction between classes.

• Dealing with Generalization Abstraction has its own group of refactoring techniques, primarily associated with moving functionality along the class inheritance hierarchy, creating new classes and interfaces, and replacing inheritance with delegation and vice versa.