Code does not age like an organic organism, but it can in its own way.
The quality decreases as time passes – software codebases degrade in quality and become more disorganized over time as more code is added and more developers touch it.
Whether you’re in a team or a single developer, when working on your project, you will realize that as time passes the code you wrote in the past can and should be improved.
Just like that, you can imagine that there are multiple things that can be improved in a codebase:
- Functionalities: As you add functionalities to your codebase, you might look at older code and think it can be improved
- Coding practices: Things change, and practices that were valid a year ago might have changed for the better
- Technical debt: it accumulates over time, mainly because opting for quick and simple solutions rather than more robust options that require additional time often leads to higher maintenance costs.
All these combined deteriorate the quality of your code, and it’s up to software engineers to keep codebases tidy and happy!
What is it: Refactoring
Refactoring is about restructure code in small predictable steps to make it easier to work with, while preserving behavior.
Why refactor?
Fixing up your old code is good because it saves you from lots of problems later. Just because some code works does not mean it is good code. How many lines of code have you written and then later on you have rewritten it because you found a better way to write the same code: length, readability, logic – anything can be improved.
Sometimes the code will work, but it might be slow since it’s written in a messy way. Or it might be hard to add new functionalities to it because it’s too complex to understand or extend. A lot of times, it’s both.
Taking time to fix your code is always a good idea. You’ll end up with much cleaner code that’s easier to keep working and upgrade. It also removes lots of chances for bugs.
It is always a good idea to set rules that help ensure your code stays tidy as your project grows too. Use tools that check style i.e. eslint in JavaScript: it statically analyzes your code to quickly find problems before you ship your code!
It’s another good idea to decide which coding standards to adopt early on. It makes reading the code much more enjoyable and other developers will thank you.
When should you refactor?
Certain situations indicate it may be time to refactor your code, there’s no wake-up alarm going off to notify you that it’s time to refactor!
- Repeating the same code multiple times suggests an opportunity to abstract common functionality into reusable modules. The DRY principle (“Don’t Repeat Yourself”) advises replacing repetitive code with abstractions less likely to change. However, balance is key – too much abstraction can overcomplicate code.
- Multiple bugs clustered in the same area of code imply low-quality code ripe for refactoring. Bug tracking tools like Dashcam can reveal these clusters.
- Adding a feature and finding messy legacy code is a cue to clean things up for better understanding and future maintainability.
- Fixing bugs presents a similar chance to refactor faulty code beyond just patching it.
- Code reviews allow preemptive refactoring before merging new code into the main branch as technical debt. Reviewers can point out areas needing improvement and make suggestions.
😅 Bad times to refactor1
- When there are not enough tests, unless you write more tests first. How do you ensure that you didn’t change behavior?
- When it’s otherwise risky to change code, e.g. just before a big marketing campaign.
- When you can foresee/suspect that there might be lots of merge conflicts for you or someone else.
- When you don’t feel confident that you understand the problem space or what the right structure might be yet.
💪 Good times to refactor
- Just after writing code. You now have the code clear in your head. You probably learned how things work, what tests are relevant, and what a better structure might be.
- Just before writing code. Refactor the code to make it easier to implement the actual change.
- After researching code, version control history, and docs (and ideally talking to people) to figure out how things work. If things don’t make sense, or e.g. poor naming made it more difficult to figure out how things work, fix that now to make it easier for the next explorer.
All in all, the time when you should refactor depends on what you’re working on inside your codebase, there are always chances for refactoring based on what you discover. Most of the time, reading other people’s code might be the best way to realize whether a fragment of code needs to be refactored.
Recognizing opportunities to improve code quality for long-term maintainability is a skill that anyone can acquire by practicing, and it’s really much more useful than just doing the bare minimum to add features and fix bugs. This is what I believe is the difference between engineering and programming!