Article summary
Refactoring is a critical component of software development. It addresses the inevitable accumulation of technical debt as a project grows. In my experience, developers on the project are aware of this but aren’t always on the same page. This leads to ideas for improving the project’s health tucked away in the minds of a few individual developers. On my most recent project, we’ve implemented a strategy to alleviate this issue: team refactoring goals.
The Problem
Let’s talk about what can go wrong when refactoring ideas aren’t shared with the team.
Sometimes the person who has the idea for a refactor isn’t able to implement their idea. Either they are busy with other tasks, or they never get the opportunity to work on the parts of the code that need refactoring. The idea will die unless shared with other developers or unless others have the same thought.
On top of this, implementing some refactors might require a lot of time. In this case, they may require one or two weeks to fully implement. No project manager I’ve met is thrilled to prioritize tech debt over features or bug fixes.
The Solution
Setting project-level refactoring goals as a team helps alleviate the two problems I outlined above.
First, not every developer gets the chance to work on every part of the codebase, and their impactful insights might be lost. By incorporating a process to advertise goals to the team, the burden of refactoring is no longer on the shoulders of one developer. Every team member now has an idea for improving the health of the code base.
Second, it allows refactoring to happen as a progressive exercise rather than a one-off task. By communicating your goals, developers on your team are more equipped to tackle tasks that bring you closer to improving the codebase. Instead of having one big bang refactor, each developer can be responsible for a small chunk of the collective goal.
Creating Effective Refactoring Goals
Setting beneficial project-level refactoring goals requires a few key steps: they must be easily accessible, flexible, and invite team input.
Accessibility
The effectiveness of refactoring goals is reliant on their visibility. If the goal is hard to access or view, its impact will significantly dwindle. Make sure you choose a platform that can seamlessly integrate with your team. In my team, we have found using GitHub Issues to be effective since all of our developers are comfortable with it and view it at least once a day. On top of this, we can easily link to our goals when leaving feedback on pull requests.
Open to Input
Encouraging your team members to contribute their thoughts and perspectives is key to gathering as many data points as possible. While you may have an excellent idea for improving the project, someone else might have a better way of implementing that idea.
Though proposing practical solutions matters, it’s crucial not to undervalue discussing code pain points. Developers often struggle in silence, feeling there isn’t room or time to address these issues. Voicing these struggles can be equally as important as proposing solutions. By allowing team members to communicate points of frustration in the project, you can expose more opportunities for improvement.
Flexibility
Refactoring goals should never be set in stone. As refactoring begins, you may realize your initial idea may not be as good as you first thought. As you learn more, your refactoring goals, too, should be capable of evolving. This means goals can accommodate new needs as the project progresses, ensuring that the refactoring efforts are consistently targeted at optimizing code health.
Conclusion
Incorporating team-level refactoring goals has transformed our project’s health. This method changes refactoring from a solitary task into a team-oriented, dynamic process, significantly enhancing our codebase. It’s through these incremental, collective steps that we not only improve our code but also progressively enhance the success of our software projects.