I acknowledge this title looks like a click bait, but at the end of the day it's true: not everything needs refactoring.
Working in large codebases isn't easy and can become a terrible experience if you don't:
- Keep improving the code as you add new features;
- Work with automated tests;
- Deprecate and remove unused code;
As the code becomes legacy and your production environment starts to experince more incidents due to your code's lack of quality, there are a few steps I like to reproduce in order to revamp the project and establish a good environment for engineers and the end user.
Work with your leaders
Even in projects that aren't breaking production because of technical bebt, there's always something to be improved. Negotiate a time on your cycles to work on technical debt and improvements. Ensure that it's a continuous effort rather than a one-time project. A few options to start including these tasks in your cycle.
- Friday-fix;
- Fixing schedule: each developer works on a improvement at time;
- A percentage of your tasks dedicated to tech-debt.
But remember: before you start working on actual improvements, communicate the current scenario to your leaders and try to propose what needs to be done. These problems need visibility.
Refactoring may introduce new bugs
Even if you have the perfect test coverage of your application, a dedicated QA team running tests of different kinds, new changes may introduce bugs. Refactoring changes included! In this case, we should avoid blaming specific people and try introducing new ways to avoid such issues from happening again (e.g.: automated tests!).
Small changes, big wins
To start with ‘big wins’, think of anything that won't require the team to learn something new and that will improve everyone's life. It can be automated solutions, code-mods, automated tests,
Automation
In some cases, introducing a better linter, an auto-formatting tool, a few code-mods, a code complexity analytics tools will ensure that new features follow a better standard in comparison to the existing codebase without introducing a new cerimony or specific task to the team.
Tests
Foster the automated tests culture. Whenever you change a piece of code, try adding a test. New bug? Try adding a new test to prevent it from happening again.
It can be annoying in most cases, but it's worth doing. Refactoring without tests is a risky approach.
Priotization
Priotizing technical debt isn't easy, but you can build your own board to help you determine small improvements that can solve critical issues, especially the ones users care and actually use.
Most of the times it's not as simple, since critical issues usually require a larger initiave, but in these cases, try to break it down in smaller parts and iterate over time.
Communicate with your peers
As these enhancements start to become the standard for your team, send regular notes about the improvements your team has been acomplishing. It can hard to follow all the changes and some people may start loosing track. Try sending weekly
Not everything needs refactoring
That's the title of this post, and you propably read everything waiting for this but this idea here is quite simple: If a feature is not being used, is not critical, might be replaced soon, has a complex context, or might introduce conflicts with other branches, you should consider not refactoring it at this stage.
Simply acknowledge it as a tech debt. Additionally document/comment and explan why the team is not prioritizing that change at the moment and move on. In the future, the team may consider it's the right time to improve that part of the codebase based on your own board of priorities.
