Refactoring
The decision for a better tomorrow
As a developer meeting deadlines are the most important thing, we always have to have something to deliver to stakeholders, even if it is not on his optimal condition, but in order to make an app scalable, it is essential to clean your code.
When to refactor?
Many reasons will indicate that your code needs some refactoring, let's name a few.
- There is a repetitive code, if changes are needed in this particular part you would need to make sure to change all other parts where this code is being repeated.
- The code is difficult to read, usually a sign of what it is called code smell, like methods and classes that are so big that they are hard to work with or classes being tightly coupled, etc..
- Making changes in a feature or adding a new one, is causing a bug in an unchanged part of your code.
- Inheriting legacy code.
- Technical debt.
Refactoring Techniques
- Composing methods — The techniques in this group streamline methods, remove code duplication, and pave the way for future improvements.
- Moving features between objects — These techniques show how to safely move functionality between classes, create new classes, and hide implementation details from public access.
- Organizing data — These techniques help with data handling, replacing primitives with rich class functionality. Another important result is the untangling of class associations, which makes classes more portable and reusable.
- Simplifying conditional expressions — These techniques combat the complicated logic expressed by conditional expressions.
- 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 — These techniques are primarily associated with moving functionality along the class inheritance hierarchy, creating new classes and interfaces, and replacing inheritance with delegation and vice versa.
What is Technical Debt
The technical debt metaphor was coined by Ward Cunningham. Technical debt refers to the cost of using poor development decisions in order to create a solution faster instead of taking a longer approach, usually to meet deadlines. As with monetary debt, if technical debt is not repaid, it can accumulate interest, making it harder to implement changes.
Refactoring is a way of removing or reducing the presence of technical debt. However, not all technical debt can be paid by refactoring.
