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

Question

问题陈述：

Given:

• TFS作为源代码管理
• 沉重的桌面客户端应用程序与大量的遗留代码与糟糕或几乎缺席的架构设计。
• 客户不断要求新的功能，有良好的质量，fast交付和不断抱怨用户不友好的用户界面。

问题：

应用程序无疑需要深入重构。这一过程不可避免地需要应用程序的不稳定和专用的稳定阶段。

我们试过了：

从主(MB)到特征分支(FB)的定期合并的主站重构。(我的错误)结果:许多不稳定的分支。

我们得到的建议：

链接到文章(pdf)

创建用于重构( RB )的附加分支，通过从MB到RB的合并，定期将其与MB同步。在RB稳定之后，我们用RB代替主程序，并创建新的分支来进一步重构。这就是计划。但是在这里，我期望在将任何FB合并到MB之后，将MB合并到RB。

主要优点:多数时间掌握稳定。

除了这个程序，还有什么更好的选择吗？

Answer 1

我过去也有过类似的情况。我所做的：

• 评估项目的当前状态；在大多数情况下，架构(或缺乏架构)是=>重新思考的主要问题。
• 通常有工作特性，问题是项目各个部分之间的高度耦合；我评估哪些是工作特性，并重用它们，但在我自己的体系结构中。
• 与客户交谈；我不知道你的经理说了些什么，但我认为与客户交谈和坦率是很重要的；他需要知道你正在努力提高他产品的质量。我就释放计划达成了协议：
• 在合并这2种解决方案(使体系结构+旧项目的重用特性)的阶段中，发布的唯一东西(新特性)是在旧产品上发布的；然而，新版本只包含重要的bug修复。所以在旧产品上发布的很少。因此，修改后的内容很容易被合并到新的解决方案中。
• 第一个新版本(新产品的发行版)只包含旧产品所包含的内容(没有新特性)；在稳定它之后(稳定时间不长)，我使用了一个项目。

我认为你无法逃避(相当短的)一段时间的零星发布。重要的是你能和你的客户达成一致。