Você re-projetaria completamente em .Net?


8

Um aplicativo muito extenso começou como um sistema baseado em Access (para armazenamento de banco de dados). Os formulários foram escritos em VB5 e / ou VB6. Como o .Net se tornou um elemento importante na comunidade de desenvolvimento, certos módulos foram reescritos. Isso parece muito complicado e potencialmente caro apenas para manter por causa das tecnologias cruzadas e trabalho extra para manter as duas tecnologias felizes uma com a outra. Obviamente, o aplicativo usa uma mistura de ODBC OleDb e MySql.

Você acha que gastar tempo e recursos para desenvolver completamente o aplicativo em .Net seria mais econômico? Em um esforço para desenvolver um aplicativo mais estável, não faria sentido usar o .Net? Ou continue perseguindo os bugs do Access, adicionando novos recursos no .Net (que podem ou não criar novos bugs entre o .Net e o Access) e reescrevendo os módulos antigos do Access em módulos .Net com restrições de tempo que impedem o design e o desenvolvimento adequados?

Atualização O aplicativo usa OleDb e MySql - corrigi minha declaração anterior.

Além disso, para dar mais suporte à reescrita: desde então, descobri que, quando a "portabilidade" para .Net começou, o código VBA / VB6 existente era basicamente traduzido para o equivalente .Net. Pelo meu entendimento, nada foi feito para melhorar o desempenho ou tirar proveito de novas bibliotecas ou tecnologias.

Na minha opinião, isso cria um aplicativo muito frágil e instável. A cada nova atualização, isso se torna cada vez mais visível. Como técnico de suporte técnico, notei um aumento nos problemas relatados. Os clientes que usam o software notaram um aumento nos problemas e estão comentando.


4
Você precisaria provar ao seu chefe (ou a quem mais decidir) que vale a pena. Se já é ruim o suficiente, você provavelmente receberá o erro. Não subestime a tarefa de reescrita - você gastará muito mais tempo do que o esperado para torná-la com qualidade de produção.

1
Por que o aplicativo usa ODBC e MySql?
precisa saber é o seguinte

Respostas:


16

Muitas pessoas desencorajam a reescrever um aplicativo do zero e às vezes eu concordo com o raciocínio. Mas, na maioria das vezes, acho que reescrever o aplicativo é a solução menos dolorosa e qualquer coisa escrita no Access precisa ser portada para o .NET - PERIOD. Não me interpretem mal, o Access tem seu lugar e pode fornecer muitas funcionalidades a uma organização, mas se ele se transformar em um aplicativo completo em que as pessoas confiam, o acesso ao Google cresceu.

Provavelmente não levaria muito tempo para portar o VBA existente para o .NET em uma conversão um por um. Mas isso pode não ser uma ótima solução se o VBA não for muito bom para começar. Uma reformulação / reescrita levará mais tempo para ser escrita, mas, a longo prazo, será muito mais fácil de manter.

Estou quase sempre no campo de reescrevê-lo do zero no que diz respeito ao Access e nunca me arrependi disso.


Todos aqui têm boas respostas e me deram uma pausa para considerar seu ponto de vista. Sua opinião, @Walter, é onde estou. Eu não considero o VB mal escrito por qualquer meio. Mas é VB. A loja está escrevendo VB desde o início. Eu sou o cara novo com experiência em VB.Net e C #. Foi-me dada margem para escrever em c #. Então, é claro, tenho idéias e quero implementá-las.
iAbstract

7
+ 1 milhão para "qualquer coisa escrita no Access precisa ser portada para .NET - PERIOD". O acesso é um brinquedo.
Steven A. Lowe

1
Eu posso atestar a resposta de Walters. Eu pessoalmente trabalhei em um projeto para reescrever um serviço da Web C ++ com erros em C # (.Net 2.0) e um aplicativo da Web ASP.Net 1.1 no ASP.Net 2.0 com AJAX para um grande banco australiano. O projeto foi um verdadeiro sucesso e nós éramos uma pequena equipe focada de 5. Duas coisas que devo destacar. 1. Comprometemo-nos a oferecer suporte a problemas de produção na versão antiga até que a nova versão esteja pronta, mas sem adicionar novos recursos. 2. A não ser que realmente críticos sem novos recursos foram adicionados ao código reescrito, apenas uma característica funcional por cópia recurso com bugs corrigidos, melhoria de desempenho, etc.
softveda

1
Se todo mundo conhece VB, escolher C # em vez de VB.net é uma péssima escolha. Só porque tem {} não significa que é o melhor para todas as soluções. VB woudl se encaixam muito melhor neste caso.
gbjbaanb

E é por isso que você não deve pular para o "vamos reescrever" - a Pratik (ou seus sucessores) agora está suportando um projeto antigo do ASP.NET 2.0 / Ajax / .NET framework 2.0 desejando poder reescrevê-lo em algo moderno, talvez C + +11 :-)
gbjbaanb

5

Eu concordo com a abordagem de refatoração. É bem provável que esse seja um processo lento que pode levar muitos meses para ser concluído, mas a movimentação de um recurso / seção por vez tem grandes vantagens, incluindo:

  1. Os recursos do produto são mantidos.
  2. a capacidade de fornecer uma nova versão é mantida.
  3. A pressão do tempo é removida.

Boa sorte


A refatoração está em andamento há pelo menos um ano e está programada para continuar nos próximos um ou dois anos. Parece que os recursos poderiam ser: (1) melhor utilizados para manter o estado atual do aplicativo e corrigir bugs e (2) projetar o aplicativo para ser totalmente .Net e migrar os recursos .Net atuais para o novo design. Parece que, com um bom núcleo .Net, o aplicativo pode ser mais flexível, estável e mais tolerante ao adicionar novos recursos.
iAbstract

Lendo a pergunta, parece mais que o aplicativo foi portado, mais ou menos como refatoração, o que envolveria reorganização, alteração e teste.
Michael Shaw

2

Geralmente, é uma prática desencorajada "reescrever" um aplicativo a partir do zero (que é um desejo normal que muitos programadores sentiram pelo menos algumas vezes na vida), porque você passará de um aplicativo com conjunto de recursos conhecidos (e bugs conhecidos também!) para um aplicativo com provavelmente um conjunto menor de recursos e mais importante - bugs desconhecidos. Os usuários podem ficar frustrados, etc.

Você provavelmente ficaria melhor se refatorasse lentamente seu aplicativo por um período de tempo, evoluindo assim sua arquitetura por um longo período de tempo.


Os usuários já estão frustrados. Depurando .Net é muito mais amigável e rápido do que tentar depurar o Access. Além disso, uma ampla estrutura construída sobre uma tecnologia que, francamente, não foi projetada para uso e funcionalidade tão extensos, é um desastre que está prestes a acontecer - especialmente a IMO, quando você começa a tentar integrar uma nova tecnologia. A integração do .Net ao Access geralmente pode significar que você não está usando o .Net em seu potencial máximo devido às limitações do Access.
IAbstract

1

Um grande desafio que experimentei ao reescrever essa escala é ter que manter duas bases de código ao mesmo tempo. Se você corrigir um erro no sistema legado, verifique se a funcionalidade funciona corretamente no novo sistema e vice-versa. A atualização de um módulo por vez minimiza essa dor de cabeça na manutenção.

Um conjunto completo de testes de regressão executado nos sistemas legados e de substituição também seria útil.


Esse é exatamente o desafio ... qualquer coisa que seja corrigida na base do Access deve ser testada quanto à compatibilidade com a base .Net - e vice-versa.
iAbstract

A outra desvantagem da reescrita do zero é que os usuários não recebem nada até que você termine. Pelo menos com a substituição de um módulo por vez, eles têm a chance de ver algumas melhorias em breve.
Larry Coleman

0

Eu concordo com Jas, não reescreva aplicativos apenas por reescrever. Talvez eles nunca precisem ser depurados ou aprimorados, então por que perder tempo? No entanto, se você sentir que há uma mudança na experiência dos novos desenvolvedores contratados do Access para .NET, talvez seja necessário migrar antes que seja tarde demais. Parece improvável, mas uma possível consideração.

Embora possa não ser lucrativo do ponto de vista de desenvolvimento, como a difusão de aplicativos diferentes afeta os usuários? Requer mais treinamento do usuário? Eles estão cometendo mais erros. Aumenta o número de chamadas de suporte porque elas não conseguem encontrar algo?


A maior mudança na refatoração de módulos individuais é a maneira como os formulários procuram o front-end e a migração para o MySql no back-end. Existem algumas pequenas alterações funcionais às quais os usuários precisam se acostumar. Mas, na maioria das vezes, há reciclagem, independentemente do número de modificações, novos recursos etc. Geralmente, temos falhas no Access (formulários, dados, etc.) que forçam o reinício do programa, mesmo que a parte .Net ainda tenha algum nível de resposta.
iAbstract

0

"Você acha que gastar tempo e recursos para re-desenvolver completamente o aplicativo no .Net seria mais econômico?"

Esta não é uma pergunta que possa ser respondida aqui.

Do topo da pirâmide de requisitos: alguém tomou uma decisão que, esperançosamente, pode justificar com um plano de negócios. Nesse plano de negócios, ele deve declarar quantas horas + custos extras são necessários para converter o aplicativo e, no mesmo plano de negócios, os benefícios são declarados também em termos de dinheiro.

Essa é a maneira de fazer isso. Se não houver plano de negócios para isso. então a resposta é primeiro trabalhar em um plano de negócios rastreável para alguns casos de uso de alto nível para fazer a análise de impacto e verificar o início do projeto.

Se o condutor original da meta de negócios que leva à mudança nem se baseia em dinheiro, provavelmente é essa pessoa que está pagando por tudo, portanto, isso deve ser feito.

Se não houver um plano de negócios, mas "apenas pronto", tente criar um e apresentá-lo à alta gerência. Inclua casos de uso de alto nível, custos, horas para reprojeto, construção, custo extra para operações, novo treinamento para administradores e usuários finais, gerenciamento de projetos e riscos potenciais.

IMHO isso não é uma questão técnica.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.