Como você continuar a desenvolver grandes (longo prazo) sistemas de software com o legado e novo código? [fechadas]

Question

Eu trabalho em uma grande base de código com uma grande base instalada de usuários. O código foi originalmente escrito em VB6 com alguns c ++ COM módulos para o trabalho de baixo nível.

É completamente inviável para reescrever todo o código que já está escrito em VB6 e está sendo usado por nossos clientes todos os dias, mas também estamos continuando a melhorias fazer e personalizações para o software (grandes e pequenos).

Minha solução até agora é escrever a maior parte do novo código em C # (winforms e até mesmo WPF agora) e, em seguida, usar interoperabilidade COM para chamar os módulos de VB6.

Alguém lá fora, têm experiência com suítes de software de longo prazo como esta (10 + anos) que não pode ser interrompido por uma reescrita completa, mas precisa novo desenvolvimento contínuo, ao mesmo tempo. Além disso, em sistemas mistos como este, o que é a melhor maneira para fazer a interface dos módulos? Eu estou usando COM agora, mas ter considerado IPC com processos separados bem.

Answer 1

É difícil dar uma única tudo resposta abrangente, mas a abordagem de alto nível é clara. Pelo menos, esta é a abordagem que eu usei. Priorize seus objetivos e, em seguida, tentar identificar os custos de atingir essas metas. Seus custos será essencialmente se resumem a 'tempo desenvolvedor'.

Primeiro, você quer o que está trabalhando para continuar trabalhando. Se você tem algo que está funcionando, e não há nenhuma boa razão para reescrevê-lo, mantê-lo.

Se algum do seu código existente precisa de atualização para fazer seu trabalho, então você está olhando para os custos de manutenção. Neste ponto, você precisa determinar se uma reescrita irá melhorar os custos de manutenção o suficiente para valer a pena. Não se esqueça de subtrair teste e depuração de novos bugs porque haverá novos bugs. Não descartar código de trabalho só porque ele é velho.

Se o seu código existente é suficientemente modular, normalmente você pode desbastar-lo uma peça de cada vez. Reescreva os componentes de manutenção elevados em primeiro lugar.

Se você vai fazer novo desenvolvimento em C #, em seguida, você deve estar bem trabalhar com componentes COM até que você tenha justificação suficiente para substituí-los.

Answer 2

Eu acho que você tem um plano bom. Isto acabará por passar a maior parte do código em C #, aproveitando o melhor conjunto de ferramentas.

O Código VB6 objetos compreendem COM?

Você mencionou que o código "não pode ser interrompido por uma reescrita completa". Mas você não tem que parar. Um por um, você pode substituir cada pedaço de funcionalidade VB6 com o código equivalente C #. Isso permitirá que você para fazer uma mudança em um momento (de preferência com testes automatizados para provar que você não ter quebrado nada).

Answer 3

Re-escrever em uma base necessidades quando há um fator motivador.

Um projeto antigo do Windows em que trabalhei tinha um motor de regras escrito em C que estava trabalhando então apenas à esquerda-lo como uma DLL caixa preta.

Nós construímos um novo front-end e a base de usuários foi ficaram impressionados com o fácil de usar novo visual moderno da aplicação. Nada nos internos tinha realmente mudado.

A camada de acesso a banco de dados estava usando SQL Server DBLIB e não foi re-wrtten até que nós atualizado SQL Server.

Answer 4

Temos vários sistemas deste tipo. A parte preocupante de tudo isso é o ciclo de vida status de suporte de VB6 . Existe o risco (mesmo que pequena) que você não vai ser capaz de obter ajuda da Microsoft com uma questão showstopper com por exemplo, um upgrade de servidor futuro, e não terá a capacidade de corrigi-lo sozinho (por exemplo, devido a incompatibilidades entre o VB6 DLL eo servidor remendado O / S). Este é um risco a sua gestão possa estar interessado no - mas, em seguida, se você não tem nenhum contratos de suporte agora, talvez eles estão confortáveis ??com isso?

Na verdade, estamos olhando para reescrever e redesenhar alguns dos mais críticos. Nós tentamos evolução incremental, e pode funcionar, mas faz para um (digamos) operações interessantes e situação de manutenção. Eu recomendo fortemente instrumentação tudo (código antigo e novo) com abundância de logging configurável, se você não for já, para ajudar com isolamento de falhas.

COM soa como uma interface razoável entre legado e novas. A menos que você tem interações muito simples entre os componentes, eu realmente não posso ver por que você gostaria de voltar para um mecanismo mais básico IPC. COM tem suas complexidades, mas também fornece uma série de abstrações úteis para, por exemplo, Dados de digitação e controle de versão que você tem que reinventar e manter ...

Answer 5

Eu acho que você precisa de olhar para os seus caminhos de atualização para seus clientes. O fato é que, em algum momento, quando eles têm 16 processadores de núcleo que você está indo querer concorrência para acelerar as coisas. Então você tem um caso de negócios para se afastar forma VB6 e para WCF. WCF tem suporte embutido simultaneidade e sincronização. Ele pode ser usado para a comunicação de proc local, bem como através do processo de comunicação e transversal à máquina. Ele também tem a vantagem de permitir que você faça mais de programação estilo AOP.

Answer 6

Eu sou atualmente um dos vários desenvolvedores trabalhando em um sistema legado grande que começou como uma combinação de C e C ++ com Win32 e, depois, MFC com um punhado de montagem entre o código de back-end C. Temos recentemente saltou de VC ++ 6 para o Visual Studio 2005 (e desde então atualizado para 2008) para a versão mais recente do projeto que estamos trabalhando. Desde a atualização IDE / compilador, estamos limpando alguns dos a aparência e têm adicionado gerenciado C ++ com WinForms e agora C # com WCF.

Embora os fundamentos do nosso sistema, incluindo o back-end, irá quase certamente permanecer em C (pelo menos no futuro previsível), nada de novo no front-end provavelmente será feito em C # / WCF. Quando temos o tempo e / ou necessidade, temos a intenção de começar a substituir partes mais antigas da extremidade dianteira com código equivalente C # / WCF.