Refactor Collision

Often hay gets baled when it's hay-baling time. When it's BleedingObvious to everyone that the hay needs baling they all go out and bale without any predetermined signal. But you can't get the same hay into two different bales ...

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?

Doesn't happen: The probability of a collision is low, since refactoring is usually done on the basis of a signed-up task, and usually people don't work on the same classes.
First edit wins: When it does occur, since we strive for ContinuousIntegration, first guy in gets it. Second guy discovers an edit conflict and has to fix it. Would call on first guy if need be.
Rapid Development Reduces Conflict: Since we don't do anything that takes more than a couple of days, and most tasks take less than a day, it's rare that anything BIG is going on. This keeps conflicts down as well.
Simple is Simple: Since the purpose of refactoring is to simplify the code, it isn't likely that there will be a conflict anyway. In the vase majority of the cases, one idea is visibly better than the other. Go with it. If there's no visible difference, you should just pick one, but I honestly haven't ever seen it happen.

Even in a larger-scaled situation I'd expect this to remain true. In the larger team, you would probably move away from CollectiveCodeOwnership long before you got into this problem.

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

EditText of this page (last edited December 8, 1998)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006