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?
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.