All this refactoring is all very well, Martin, but there is a cost. When a piece of code that you are currently working on gets refactored out from under you, you can end up with the merge from hell. I've just spent two hours merging a perfectly sensible set of refactorings into a change I'm making. Methods were renamed and moved, all to better names and places, but the changes were well beyond what Suvbersion can deal with automatically.
What's the solution to this? I have no idea. ;-) Certainly the refactoring of code that is hard to understand or maintain is necessary if you are to keep your code-base workable.
One piece of advice is to check in little and often. This doesn't make the issue go away, but does limit its impact.
The other thing is to bear in mind the potential cost of the refactoring that you are doing. Renaming that isPlayable() method to isVideoPlayable() might not be such a good idea, even if it is a better name, if it's going to cost someone hours of work.
Another advice for you is to update often, especially when you're planning on doing a big refactor. Then you'll know sooner than later that you're off.
Posted by: Aslak Hellesøy on November 8, 2007 04:17 PMSounds like a communication issue.
Posted by: Tim on November 8, 2007 05:11 PMAslak: Absolutely right. As with updating often, doesn't fix the issue, but lessens its impact.
Tim: True, but in a big team, it becomes impossible to keep up with what everyone else is doing.
Posted by: Simon on November 8, 2007 05:42 PMThen your team and/or codebase is too big. Break it up in smaller independent sub systems and teams.
Posted by: Aslak Hellesøy on November 8, 2007 11:57 PMAt least in Eclipse (maybe other IDEs too) you can record your project's refactorings and replay them over other projects that depend on it.
One of Eclipse's projects (sorry, don't remember which since it was already some months ago) already used this feature together with its dependent projects by publishing their refactorings together with a new version.
Posted by: Paulo Gaspar on November 9, 2007 12:47 AMOr you could try using Conflict server on your project. It might not help the fact that your code needs refactoring, but it should help it happen a little more smoothly......
Posted by: Ben Hughes on November 9, 2007 01:25 PMAslak,
Team or codebase too big? It's a big project! There's no natural way to split it. I'm not saying that it would be impossible, but hard, and probably expensive too.
I'm not throwing the baby out with the bathwater here - refactoring is still worth doing much of the time. I'm just suggesting that people be aware of the cost, both in terms of their own efforts, and the work they might be causing other people.
Posted by: Simon on November 23, 2007 11:04 AMI have such happy memories of enterprise development. Ultimately, classic software engineering techniques are the only real defence to needless refactorings (or instability): I tended to work against stable snapshots of project code (as decided by me, not the project), ensuring that for at least a short period of time I could actually keep developing my part. Complaints about development processes were duly delivered to the appropriate project managers, who probably resented the advice.
Sometimes you have to treat even your "projectmates" as just another supplier of code.
Posted by: Paul Boddie on November 27, 2007 12:28 AM