In some methodologies there's so much BigDesignUpFront that supposedly refactoring never happens. In others, XP especially, people apparently refactor more often than they breathe. So you may get two independent developers both fixing the same cruft ... but with different refactorings in mind. How do you keep things integrated? Is this a real development scaling issue?
Biggest caveat, I suspect, is the toolset. Refactoring is incredibly fast and easy in Smalltalk, especially with the RefactoringBrowser. In Java or C++ it's just not as easy. But even here, I suspect the impact will be directly against RefactorMercilessly, rather than causing RefactorCollision's.
You can indeed do this in C++. You just have to have a versioning tool with a merging model like CyclicCvs, ClearCase, or later versions of VisualSourceSafe. There is another issue on large projects though; people want to be able to test their new code against stable versions of the code base, which in practice means precompiled libraries as of a well known revision. In XP this might be as of the end of the last UserStory in XP. Maybe also keep the libs from the last Iteration around too since it won't cost much.
Doing RefactorMercilessly with large populations of deployed components in N-tier architectures, however, could still encounter interesting scaling problems. Visual Studio 6/MTS/MSMQ and other goodies from MicrosoftCorporation make this far from a moot point these days - anyone got clear ideas on the MS implications? --PeterMerel
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004