Conversão Delphi para Prisma?

5

No meu escritório, estamos prestes a embarcar em uma jornada épica de conversão de uma antiga aplicação Delphi 5 para algo mais moderno. Uma de nossas opções é converter para Delphi Prism, mas queremos ver quais opções estão disponíveis para nos ajudar. Até agora, tudo que encontrei é Oxidizer (trabalhei pela última vez há 2 anos). Existem outras opções para nos ajudar a converter razoavelmente rapidamente para Prism? Obrigado.

    
por Tom A 12.05.2011 / 01:07
fonte

1 resposta

2

Como muitos comentários sugerem e incentivam, reescreva, sim. Por quê? Muitas dessas razões foram mencionadas nos comentários, notadamente o grau decrescente de suporte direto a idiomas e ferramentas, suporte a componentes de terceiros, mas também não mencionado é um declínio no talento disponível para manter o navio funcionando. É o mesmo problema que muitos dos projetos da era do mainframe e dos derivativos diretos enfrentam: o talento e o interesse por esses tipos de sistemas estão diminuindo.

Um dos maiores desafios para um esforço de migração não é qual idioma ou plataforma ou conjunto de ferramentas, especialmente hoje: há muitas boas opções, algumas melhores que outras, dependendo do que se está tentando realizar e esperar o esforço resultante. Hoje, o maior desafio, como tem sido há anos, é encontrar o talento certo para traduzir o sistema antigo para o novo, ou pelo menos traduzi-lo suficientemente bem e eficientemente para que outros possam construir o novo.

No caso do OP, parece que eles não têm apenas profissionais habilitados não apenas na linguagem e no ferramental legado, mas também em um grau altamente familiarizado com o cliente e o domínio. Isso é uma grande vantagem.

O que eu sugiro, com base em minha experiência com projetos de migração legados genuínos, é dar um salto maior enquanto houver experiência no final da origem. Torna-se monumentalmente mais difícil quando esses construtores e mantenedores saem.

  1. Avaliação do uso e estabilidade do sistema. O sistema está fazendo as coisas que o cliente precisa, nem mais nem menos? São suas peças particulares que podem ser isoladas até certo ponto? Há peças que atormentam o desenvolvimento porque são propensas a quebras ou queixas frequentes? Há partes da perspectiva do usuário que estão faltando (casos de uso que se encaixam no escopo do sistema que não foram identificados)? E assim por diante ...

  2. Use essas informações da avaliação de uso e estabilidade para iniciar um projeto de incubação, derivado, para chegar a uma plataforma mais mainstream em que as ferramentas e o treinamento serão abundantes no futuro previsível. Use uma mistura de arquitetura / reengenharia e portabilidade direta para decolar.

  3. Prove as novas peças usando a implantação seletiva e em fases para os usuários.

  4. Avalie o progresso do esforço gasto.

  5. Aumente a migração se tudo estiver funcionando como planejado.

EDITAR:

Recomendações pessoais:

  1. C # em uma plataforma Windows ou da web, pois ele fornece familiaridade de várias maneiras ao Delphi, e será o cavalo de tração da Microsoft por um tempo.

  2. Possivelmente uma incursão no celular. Depende do que o cliente precisa e quer, pois isso pode mudar a forma como eu priorizaria isso. Uma das coisas que o Radar da ThoughtWorks sugere é que muitas empresas estão adotando uma estratégia de mobilidade para novos projetos. Eu pessoalmente estaria inclinado a sugerir a rota do Android se estivesse olhando para aplicativos nativos, principalmente porque é difundido, mas também no caso do OP, o Java móvel seria uma transição bastante confortável do Delphi. O Google definitivamente não vai se afastar disso tão cedo.

  3. Ada. Brincadeira.

  4. Possivelmente Python ou Ruby. Sou um tanto agnóstico em relação a ambos, mas eles certamente têm algum mérito.

por 26.10.2012 / 04:40
fonte

Tags