The refactoring of Git branches can provide many benefits, including:
- Fast-tracking urgent changes created as part of feature development in the main branch (before the new feature is merged)
- Improving the quality and efficiency of code reviews while making them fun (by allowing team members to review and merge various changes individually in larger branches)
Refactoring happens from time to time. It allows developers to:
- Fix any bugs in essential areas of existing code
- Add functionality that may be missing from existing code (especially if a new feature requires it)
- Extract pieces of code and make them separately available
- Improve overall code quality
- Generally clean up the codebase in positive, meaningful ways
With so much upside to refactoring, it’s hard to believe that there are reasons it shouldn’t be done. And yet, there are.
The danger of (too much) refactoring is that it can end up acting as a trigger that begins to expand the scope of all (or a portion of) the project. What starts off, innocently enough, as an optimization endeavor starts to become an entire re-write – and if you let it spiral, you’ll lose control of your end-goal and the project timeline pretty quickly. You may even see your costs balloon. That’s why it’s essential to be mindful of refactoring and of having clear goals at the outset.
The First Step: Recognizing If You Have a Problem
The ugly truth is that code doesn’t age well, and if your project is around for long enough, bits or refactoring here and there will help keep it healthy and up to spec.
While it’s quite good and completely natural to have a small amount of refactoring happening, the first sign that a refactoring assignment has jumped the shark is when there’s a sudden uptick in changes in areas utterly unrelated to the feature in question.
Be sure to check work logs for more significant than average code commits in a set of files that, to the naked eye, seem unrelated to each other. As product teams rarely actually expand refactors, it’s best to go directly to your engineer and get a sense of what’s going on.
Dealing with an Expanded Refactoring Exercise
When dealing with expanding refactoring, it’s a good idea to go directly to the team to begin an open discussion on the matter. Ask members to make the case both for and against. By looping them in and coming to a decision together, everyone will be on the same page regarding expectations. As a collective, you can then decide whether it’s best to move forward, drop it altogether, or take stock of it during a different project entirely.
This also gives you an excellent opportunity to go back and revisit general standards and redefine what success is in the context of the more critical project goals. What does it look like to “win”? What are the bare minimums, and where are there gaps that need to be addressed to ensure sprints run smoothly. In short: it’s an excellent time to clarify expectations and to decide/do a refresher on the rules of the road. It’s also great to make sure everyone’s on the same page about what the project is and, more importantly, isn’t. Once everyone is clear of the scope, less time will likely be spent on expanding refactoring as the general goals have been reintroduced to the entire team, and, hopefully, the scope has been made clear.
Conclusion
Refactoring is a part of life. However, it can quickly get out of hand, and your team might miss the forest for the trees in terms of reaching predefined goals if they get caught up in a refactoring spiral. Once you sense refactoring is taking over a project, circle back with the entire team and remind each other of the bigger goals. Then decide how refactoring fits into them (if at all).
Let us help you integrate Git with Jira. Check out all of our great highly-rated plugins for Bitbucket, GitHub, Gitlab (and more) available now on the Atlassian marketplace.
Want more Bitband insights? Check out:
