寻找将深度架构重构与基于功能的开发相结合的更好方法

问题陈述：

鉴于：

• TFS作为源代码控制
• 繁重的桌面客户端应用程序，带有大量不良代码或几乎没有架构设计的旧代码。
• 客户不断要求具有音质，快速
  交付的新功能，并不断抱怨用户界面不友好。

问题：

应用程序无疑需要深度重构。此过程不可避免地使应用程序不稳定，需要专用的稳定阶段。

我们尝试过：

通过从主节点（MB）到功能分支（FB）的定期合并在主节点中进行重构。（我的错误） 结果：许多不稳定的分支。

我们的建议：

链接到文章（pdf）
通过从MB到RB的合并，创建附加的重构分支（RB）使其与MB定期同步。RB稳定后，我们用RB代替master并创建新分支以进行进一步的重构。这是计划。但是在这里，我期望在将任何FB合并到MB之后将MB合并到RB的真正地狱。

主要优点： 大部分时间稳定掌握。

有没有更好的替代方法？

我过去也有类似情况。我做了什么：

• 评估项目的当前状态；在大多数情况下，架构（或缺乏架构）是主要问题=>重新思考
• 通常有工作特征，问题是项目各个部分之间的高度耦合；我评估了哪些工作功能并重用了它们，但使用的是自己的体系结构

• 与客户交谈；我不知道您的经理怎么说，但我认为与客户交谈并保持坦率是很重要的。他需要知道您正在努力提高产品质量。我已同意发布计划：

• 在合并这两个解决方案的阶段（使体系结构+旧项目的重用功能），唯一发布的内容（新功能）是在旧产品上完成的；但是，新版本仅包含重要的错误修复。因此，在旧产品上几乎没有发布任何版本。因此，更改后的内容可以轻松合并到新解决方案中。

• 第一个新版本（新产品的发行版）仅包含旧产品所包含的内容（没有新功能）；稳定下来（稳定时间不长）之后，我处理了一个项目

我认为您无法摆脱（偶尔很短的）零星发行。您必须与客户就此达成共识，这一点很重要。