Eu tenho dois aplicativos, chamados A e B. A versão atual desses aplicativos é 7.x (alguns clientes executam 7.1, outros executam 7.2, ...). Ambos os aplicativos usam uma mesma estrutura comum (vamos chamar de C), assim:
+---+ +---+
| A | | B |
+---------+
| C |
+---------+
Por causa de alguns clientes novos e importantes, quero ter a funcionalidade de A e B em um grande aplicativo. Não é possível mesclar A e B em um aplicativo, então agora estou tentando integrar a funcionalidade de A em B. Até agora tudo bem, mas estou começando a encontrar alguns problemas.
Antes de tudo, os clientes que usam apenas a funcionalidade básica de B não estão interessados em todas as novas funcionalidades de A adicionadas (e que causam sobrecarga adicional para eles). Eles só querem atualizar sua versão B com suporte para novas versões do Windows, ... e talvez também desejem todas as boas funcionalidades adicionadas ao C (a estrutura comum).
Segundo, os clientes que atualmente estão usando o aplicativo A não desejam ir diretamente para o aplicativo B, embora a funcionalidade combinada do A + B os ajude a longo prazo. Para atualizações fáceis, eles querem ficar com A e até ver algumas melhorias em C.
Terceiro, todos os desenvolvimentos que estou desenvolvendo em B podem ter um impacto na camada comum CEg para melhorar o desempenho de um módulo em B, preciso refatorar um módulo em C, mas como C também é usado em A, Eu preciso fazer muito mais trabalho. Além disso, A é um aplicativo mais antigo e menos estruturado, e todas as alterações em C podem tornar A mais instável.
Pergunta é como proceder? Atualmente, estou pensando em dividir B em uma versão 7.x (eu ainda poderia fazer alguns desenvolvimentos menores aqui e nas versões 7.3, 7.4 nos próximos anos, se necessário), e uma versão 8.x (que conteria todas as novas funcionalidades) . Para resolver o problema da camada comum, eu também poderia dividir C em um C antigo (7.x) e um novo C (8.x). Isso fornece o seguinte resultado:
+-------+ +-------+ +-------+
| A 7.x | | B 7.x | | B 8.x |
+-----------------+ +-------+
| C 7.x | | C 8.x |
+-----------------+ +-------+
O aplicativo A não evoluiria mais e permaneceria na versão 7.x da camada comum C.
Dividir C significa que todos os desenvolvimentos em C não serão vistos nos antigos A e B (que ainda seriam a versão 7.x), ou se precisarem ser feitos na liberação 7.x de A e B, exigirão a execução do procedimento desenvolvimentos nos dois lançamentos.
Uma alternativa poderia ser dividir B em B 7.xe B 8.x, mas isso limitaria as possibilidades de refatoração em C e, na verdade, resolve apenas os dois primeiros problemas.
Alguém tem alguma experiência com esse tipo de mudança de versão importante? Alguma outra ideia?
fonte
Respostas:
Normalmente, isso é apenas um problema de interface do usuário: leve a funcionalidade de A para o aplicativo combinado "B 8.x", mas separe-a de uma maneira que não será vista pelos clientes de B no nível da interface do usuário. Crie um switch no aplicativo para ativar a funcionalidade A apenas para "clientes A". Provavelmente, você precisa ter outra opção para ocultar a funcionalidade B para clientes A (isso também oferece a chance de vender a funcionalidade B como um módulo separado)
Eu acho que isso não será problema se você se importa com duas coisas:
Por fim, se você puder migrar seus clientes A para B 8.x dessa maneira, resolverá automaticamente seu terceiro problema.
Uma coisa a acrescentar: estou mantendo um aplicativo que estava em uma situação muito semelhante há cerca de 15 anos ("A 7.x" era um programa do MS DOS, "B 7.x" era um programa do Windows com muitos recursos novos. , e "B 8.x" continha todas as funções de ambos os antecessores, onde as funções antigas "A 7.x" foram integradas em B e vendidas como um módulo separado). Você não ficará surpreso quando eu lhe disser que não temos mais clientes do MS DOS há mais de dez anos; portanto, a transição não foi um problema.
fonte