Best Practices for Renaming, Refactoring, and Breaking Changes with Teams
- by David in Dakota
What are some Best Practices for refactoring and renaming in team environments? I bring this up with a few scenarios in mind:
If a library that is commonly referenced is refactored to introduce a breaking change to any library or project that references it. E.g. arbitrarily changing the name of a method.
If projects are renamed and solutions must be rebuilt with updated references to them.
If project structure is changed to be "more organized" by introducing folders and moving existing projects or solutions to new locations.
Some additional thoughts/questions:
Should changes like this matter or is resulting pain an indication of structure gone awry?
Who should take responsibility for fixing errors related to a breaking change? If a developer makes a breaking change should they be responsible for going into affected projects and updating them or should they alert other developers and prompt them to change things?
Is this something that can be done on a scheduled basis or is it something that should be done as frequently as possible? If a refactoring is put off for too long it is increasingly difficult to reconcile but at the same time in a day spending 1 hour increments fixing a build because of changes happening elsewhere.
Is this a matter of a formal communication process or can it be organic?
