9

Problem statement:

Given:

  • TFS as Source Control
  • Heavy desktop client application with tons of legacy code with bad or almost absent architecture design.
  • Clients constantly requiring new features with sound quality, fast
    delivery and constantly complaining on user unfriendly UI.

Problem:

Application undoubtedly requires deep refactoring. This process inevitably makes application unstable and dedicated stabilization phase is needed.

We've tried:

Refactoring in master with periodical merges from master (MB) to feature branch (FB). (my mistake) Result: Many unstable branches.

What we are advised:

Link to the article (pdf)
Create additional branch for refactoring (RB) periodically synchronizing it with MB via merge from MB to RB. After RB is stabilized we substitute master with RB and create new branch for further refactoring. This is the plan. But here I expect the real hell of merging MB to RB after merging any FB to MB.

The main advantage: Stable master most of the time.

Are there any better alternatives to the procees?

Improve this question
1
  • 1
    Possible improvements (rather than alternatives) to your proposed process: The TFS merge tool is pretty unwieldy compared to various alternative diff utilities. If you have not already done so, you may find manually merging to be less painful if you configure the TFS client to use a nicer diff utility, rather than the built in tool. You may also find Microsoft's TFS Power Tools utility to be useful. It provides the ability to run a diff between changesets or branches, rather than only between individual files.
    – Brian
    Dec 19, 2012 at 22:28

1 Answer 1

Reset to default
1

I had a similar situation in the past. What I did:

  • assess the current state of the project; in most situation the architecture (or lack of it) is the main problem => re-think it
  • usually there are working features, the problem being the high coupling between the various parts of the project; I assessed which are the working features and I reused them, but in my own architecture

  • talk to the customer; I don't know what your manager says, but I think it's important to talk to the customer and be frank; he needs to know you are working on the quality of his product. I made an agreement for a release plan:

  • in the phase of merging the 2 solutions (make the architecture + reuse features from old project) the only things that were released (new features) were made on the old product; however, new releases contained only important bug fixes. So very few releases were made on the old product. Hence the changed things were easily merged into the new solution.

  • the first new release (release of the new product) contained only what the old product contained (no new features); after stabilizing it (the stabilization did not take long) I worked with a single project

I think you cannot escape from a (reasonably short) period of sporadic releases. It's important that you can agree on this with your customer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.