Refactoring and Source Control: How To?

Question

I am completely on board with the ideas behind TDD, Refactoring and Patterns however it does seem like there is a huge gaping whole in these ideas, mainly that they are great for dev teams of 1, but when you start refactoring code that 10 people are working on you start getting merge conflicts all over the place and most diff/merge software can't tell that you refactored a function into its own class.

How do you clean up your code, by refactoring, without causing major headaches for everyone on your team?

Answer 1

Well, in practice it is rarely an issue. Usually the different team members are working on different areas of the code, so there is no conflict. Also, the bulk of the refactoring will go in when you are doing your TDD (which might even be before you check your code in, but most definitely before others start using and modifying it).

If you find you are conflicting a lot due to refactorings, try checking in more frequently, or let people know who might be working on the same code that you are about to do some major rework. Communication always helps.

Answer 2

Small changes committed often.

As for your example, you would start by creating the class, committing that change. Then adding a similar function in the class as the old one and commit that change. Then change all the references from the old function to the new class function, commit that. Then remove the old function and commit that change.

Of course, no one said it was going to be easy.

Answer 3

Communication.

Tools can't solve this for you, unless the specific tool is your email or IM client.

It's the same as if you were making any other major change in a shared project -- you need to be able to tell your coworkers/collaborators "hey, hands off for a couple of hours, I have a big change to the FooBar module coming in".

Alternately, if you're going to be making a change so major that it has the potential to cause huge merge conflicts with the work of 10 other people, run the change by them beforehand. Have a code review. Ask for architectural input. Then, when you're as close to consensus as you're likely to get, take that virtual lock on the section of the repository you need, check in your changes, and send out an all-clear.

It's not a perfect solution, but it's as close as you'll get. Lots of source control systems support explicit locks on sections of the source base, but I've never really seen those lead to good results in these areas. It's a social problem, and you only really need to resort to technical solutions if you can't trust the people you're working with.

Answer 4

Frequent check ins. Team members should be checking in their changes and re-syncing their sandboxes at least once per day. With more frequent check ins merge conflicts will occur less often and be easier to manage when they do occur.

Answer 5

You have to start slow and small. Take a portion of code and look at all of the external interfaces. You have to absolutely make sure that these don't change. Now that you have defined that start to look at the internal structure of it and slowly change it around. You'll have to work in small steps and check in frequently to avoid massive merge conflicts, which is one of the biggest problems you're going to have to work against. In a team that size you'll never be able to check everything out and magically make it all better for them. You might want to let people know ahead of time what you are going to do. (which you should always plan out what you do before you do it anyway). If other people are working on it, let them know what is going to change and how it will affect the class etc.

The biggest thing you're going to have find out before you start trying is if people are on board with you. If not, it might be a lost cause and will cause strife. In this case, bad code and a functioning team that understands the mess the way it is might be better than refactored code. In know this is counter intuitive, but a boss at my old job put it this way. He said the code is horrible, but it works, and the developers here know how it works, and that means the 1000 people using it can do their job which means we get to keep ours. We hated the code and wanted to change it, but he was right.

Answer 6

I think your team has to be on-board with your changes. If you're doing large refactorings, making big changes to your codebase and object hierarchy, you're going to want to discuss the changes as a team.

Answer 7

In my experience, merge conflicts are rarely an issue when doing small and medium scale refactoring on agile projects. Large refactoring efforts can introduce some merge pain, but if it's done in bite size chunks, the pain can be reduced significantly. Merge pain can also be reduced by using Subversion as your SCM as SVN will auto-merge non-conflicting changes.

This strategy has worked well for teams I've been a part of, and most of those teams are 4+ developer pairs.

Answer 8

I think that you should ask some questions to know why refactoring could hurts source control.

• Why are 10 people changing the same code at the same time?
• There are better tools to help you when doing refactoring/merges (maybe distributed version control)?

For the first question, maybe you haven't good separation of concerns and the code is tightly coupled. Or maybe the teams are not communicating well when assigning to tasks. For the second question, well, try some good dvcs (git, mercurial, bazaar) and see if any can help you.

Kind Regards

Answer 9

When I think a refactoring is going to be difficult to merge, I do this:

1. Warn my team that the change is coming, and check if there are any pending changes that will be difficult to merge.
2. Make sure I understand the change I'm going to make, so I can make it quickly. Enhance test coverage now, if needed.
3. Synchronize my machine to the latest source.
4. Refactor, test, and commit.
5. Notify my team, so they can synch up to my changes.

Note that I'm making my refactoring change separately from functionality changes.

Answer 10

[communication with your co-workers] "hey, hands off for a couple of hours, I have a big change to the FooBar module coming in"

Wouldn't you want to tell that when you begin working on the Foobar module, such that your commit won't be broken by the changes made half-way through that you didn't tell anyone they shouldn't make?