I don't want to make things worse!
There are plenty of patterns you can apply to code to make it more maintainable.
But sometimes, it's hard to see what are the actual benefits of these patterns. Will they actually make the code easier to change? Aren't you just trading a complexity for another?
If you feel confused about what direction to take to address technical debt, here are a few resources that will help.
🎓 Related articles
- Keeping dependencies up-to-date
My recipe for recovering from outdated dependencies and keeping healthy habits
- Is it OK to change code for the sake of testing?
It seems necessary to start adding tests on this code… but what if it makes things worse?
- If you mock, are you even testing?
Is this the real code? Is this just fantasy? Let's discuss the problem with unit testing Legacy Code and an approach you can take.
- A quick way to add tests when code has database or HTTP calls
You need to fix a bug, but you can't spend a week on it? Here's a technique to isolate problematic side-effects and write tests within minutes.
- Is it fine to use "AND" in a function name?
Finding a better name for a function is hard, especially when people have contradictory opinions on what a good name looks like…
- Don't make Clean Code harder to maintain, use the Rule of Three
If you worry that following clean code practices create more code to maintain, here's a way out.
- Are functions that simply call another function a bad design choice?
Let's see how you end up with these while trying to refactor Legacy Code and what you can do about that.
- What is wrong with boolean parameters?
And 4 ways to fix their usage in Legacy Code.