Procurando a melhor maneira de combinar refatoração de arquitetura profunda com desenvolvimento baseado em recursos

Declaração do problema:

Dado:

• TFS como controle de origem
• Aplicativo cliente de desktop pesado com toneladas de código legado com design de arquitetura ruim ou quase ausente.
• Clientes que exigem constantemente novos recursos com qualidade de som,
  entrega rápida e reclamação constante da interface hostil do usuário.

Problema:

O aplicativo, sem dúvida, requer refatoração profunda. Esse processo inevitavelmente torna a aplicação instável e é necessária uma fase de estabilização dedicada.

Tentamos:

Refatoração no mestre com mesclagens periódicas do mestre (MB) para a ramificação do recurso (FB). (meu erro) Resultado: Muitos ramos instáveis.

O que somos aconselhados:

Link para o artigo (pdf)
Crie ramificação adicional para refatoração (RB), sincronizando-a periodicamente com MB por mesclagem de MB para RB. Após a estabilização da RB, substituímos o mestre pela RB e criamos uma nova ramificação para refatoração adicional. Esse é o plano. Mas aqui espero o verdadeiro inferno de mesclar MB para RB depois de mesclar qualquer FB para MB.

A principal vantagem: mestre estável na maioria das vezes.

Existem alternativas melhores para os candidatos?

Eu tive uma situação semelhante no passado. O que eu fiz:

• avaliar o estado atual do projeto; na maioria das situações, a arquitetura (ou a falta dela) é o principal problema => repensar
• geralmente existem recursos de trabalho, o problema é o alto acoplamento entre as várias partes do projeto; Avaliei quais são os recursos de trabalho e os reutilizei, mas em minha própria arquitetura

• fale com o cliente; Não sei o que o seu gerente diz, mas acho importante conversar com o cliente e ser franco; ele precisa saber que você está trabalhando na qualidade do produto dele. Fiz um acordo para um plano de liberação:

• na fase de mesclagem das 2 soluções (tornar os recursos de arquitetura + reutilização do projeto antigo), as únicas coisas lançadas (novos recursos) foram feitas no produto antigo; no entanto, novos lançamentos continham apenas importantes correções de bugs. Pouquíssimos lançamentos foram feitos no produto antigo. Portanto, as coisas alteradas foram facilmente incorporadas à nova solução.

• o primeiro novo lançamento (lançamento do novo produto) continha apenas o que o produto antigo continha (sem novos recursos); depois de estabilizar (a estabilização não demorou muito) trabalhei com um único projeto

Eu acho que você não pode escapar de um período (razoavelmente curto) de lançamentos esporádicos. É importante que você possa concordar com isso com seu cliente.