Last time, we saw how to spot signs that your PHP code needs refactoring:
This time, let's see what it may look like when things turn bad, and how to improve the situation.
Hopefully, you won't make these pretty common mistakes.
It's not the right time...
Don't refactor in the earliest stages of the project. It's usually a complete waste of time, as you will lose energy on very unstable code instead on focusing on the business.
Your helpers have too many parameters
Developers often follow the "holy" DRY principle that invite you to merge common code to prevent unnecessary duplication.
It's a good practice. However, if you combine several functions into one big function with 5, 6, 7, 8 parameters, just for the sake of removing seemingly duplicated code, it's bad.
I've seen it many times. Any change in the common helper can introduce nasty regressions. Besides, your big function will be less readable, perhaps very hard to use by other devs.
You're constantly modifying your refactor
One of the coolest aspects of refactoring is the ability to reuse functionalities and introduce modifications without modifying the code base too much.
If you have to modify your refactor every time your need to add a new feature, then it's not the right approach.
The code contains too many "ninja tricks"
"Ninja tricks" can consist of chaining ternaries to remove unnecessary if/else. While it's often a good idea to remove the else part and other nested if statements, don't overuse ternaries.
Programming languages, especially the latest versions of PHP, may provide specific operators and structures for that, making the code shorter while keeping it readable.
You've introduced useless intermediary steps
Ineffective refactoring can result in useless intermediary methods, perhaps entire classes, that only delegate the treatment to other parts of the code.
These structures will only bloat the code in the end.
Making changes takes more time
It's probably the worst-case scenario, but bad refactoring can result in consuming significantly more time during maintenance or when building new features.
This sign is very easy to spot but pretty alarming, and you may have increased the technical debt while your goal is to reduce it.
Only you can maintain the code
Very bad sign! Good refactoring eases the maintenance and prepares the next iterations.
Your refactoring should be readable and understandable by other devs. Note that even if you're the only dev for now, which is not uncommon in small businesses, things can change quickly.
How to do better
- Write automated tests to prevent regressions and unwanted side effects.
- Follow the product life cycle: the application generates revenues, so new features will be needed. Refactoring for a more robust architecture makes sense in this case.
- Reduce bloat in classes and methods. Such refactoring (split) is often rewarding in terms of maintenance.
- Keep it simple. Sometimes, duplication is necessary or you don't actually duplicate code even if it seems so.
- Discuss your refactoring with your teammates during code reviews and use Pull Requests.
- "Eat your own dog food": check if your refactoring is readable (e.g., documentation, appropriate naming, use context).
- Don't fear the metrics: use indicators to evaluate your refactoring (e.g., less bugs, shorter delays for new features).
Top comments (0)