Refactoring dilema, why and when should it be done?
According to Martin Fowler, refactoring can be described with the following sentence:
A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
Why refactor?
The purpose of refactoring is to make the software easier to understand and modify. It will helps with the following:
- Enhances system design: by refactoring the code and applying coding best practices, the overall design of the application is better
- Better readability: when the code is refactored, it’s always easier to understand it. It also reduce global code complexity
- Enhanced performance and software efficiency: when the code is simpler, it often means it is quicker. A performance refactoring can also be done if something is considered as too slow in the applicatin
- Helps program faster: it seams wrong however developers are more likely to spend more time writing new code with non-refactor project than spending time refactoring, adding spending time to write a new feature
- Reduced technical debt: directly linked with the previous one, having a clean refactored code will reduce the technical debt, and so helps program faster
- Easier product improvement: As the code is clean and clear, extensibility is really effortless compared to non-refactored code. The application is less likely to have a regresion with clear refactored code
- Saves time and money: that’s the general consequence of refactoring code
- Improved maintenability: globaly when the code is well refactored, the system is more stable
- Easier to find a bug: during the refactoring process, it is easier to find a bug because it’s done by small change steps
When refactor?
When refactor
Let’s see when you should consider refactoring:
- When adding new feature: just sum up by Martin Fowler from Refactoring — Improving the design of existing
You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing
- On a bug fix: similarly, it can help understand the problem, it’s also a flag that the code was not clear enough
- Rule of 3: when something is used 3 times, start refactoring it
- During a code review: code review is also an ideal time to start refactoring. It’s also the “last chance” to clean up the code before it came to production. The reviewer might spot issues or unclear code that need to be refactored
When not refactor
Use cases when refactoring shouldn’t be done:
- When developing from scratch: not really interesting
- When a deadline is closed: productivity gain will show up after the deadline
- When the entire system needs refactoring: when a new feature requires such a refactoring, it often means the technical debt is too high. In this case, try to do an action plan doing steps by steps refactorings
What do you tell your manager?
It can happen that management is not seeing the true benefit of code refactoring, or at least, they don’t see the cost of not doing it!
There are some ways to approach this managing issue:
- Start with refactoring in code reviews: code reviews are part of the process, management cannot interfer with it
- Don’t ask permission: aim is to do the fastest way, if the fastest way is to refactor, and then add the feature, just do it
- Explain what values it brings to management: can be sum up by a quote of Sandro Mancuso’s book: The Software Craftsman, Professionalism, Pragmatism, Pride
Management only cares about result, they don’t care about how we do it
In conclusion, don’t be shy and do some refactoring.
Thanks for reading this article. Feel free to tell in the comments when you’re refactoring your code, and how did you deal with your management to do refactoring.
