Estratégias de migração para descontinuar a linguagem de script interna


8

Temos uma linguagem de script que usamos internamente para muitas coisas. Começou como uma simples declaração de avaliação para que rótulos dinâmicos se tornassem uma linguagem completa de Turing usada amplamente em todo o sistema.

O problema é que nunca foi projetado para isso e mostra. O ambiente de desenvolvimento é anêmico, os scripts produzidos não são testáveis ​​e, ainda hoje, não existe uma definição formal da linguagem.

Um sentimento crescente entre os usuários do idioma sente que ele fez o seu trabalho e é hora de deixar ir, mas estamos diante de um desafio difícil de migrar a base de código existente para qualquer nova solução que fosse criada. Esse mesmo argumento é usado contra a ideia de migrar.

Você já enfrentou uma situação semelhante? e se sim, quais estratégias você usou para interromper o uso do antigo e promover o novo?

Uma última coisa (graças aos idiotas ) é que muitos desses scripts não estão documentados e seu objetivo original é perdido, embora ainda estejam em uso ativo. Os scripts também são usados ​​nos sites dos clientes para personalizar o sistema, de modo que temos literalmente milhares desses scripts, grande parte dos quais não está sob controle de origem ou qualquer mecanismo de versão para esse assunto.


Resposta aceita.

Escolha difícil é essa. Todas as respostas foram um conselho bom e sólido, embora eu ache que o melhor é um híbrido dos de Moron e Oliver.

Acabei aceitando o de Oliver porque é a resposta que tem a melhor chance de ser aceito mais alto (ha! Política!). Empacotar o antigo ambiente de script em uma declaração que pode ser integrada no novo ambiente forneceria um caminho de atualização rápido e fácil.

Uma vez feito, podemos controlar uma melhor criação de novos scripts, exibindo avisos ou impedindo que scripts antigos todos juntos sejam editados ou criados, forçando o uso do novo idioma.

Obrigado a todos por sua contribuição!


4
Quando li a "última coisa (obrigado, idiotas)", pensei que você estivesse comentando sobre a inteligência do designer original.
Kyle Hodgson

2
:-D não, apesar de eu me sentir meio estranha escrevendo e hesitando por um tempo. Então, novamente, ele escolheu o nome, então eu acho que está tudo bem!
Newtopian

1
Está certo!! ......
Parvos

Respostas:


5

Outra abordagem seria portar o tempo de execução do script para a nova linguagem de script escolhida e fornecer maneiras de executar scripts herdados dentro da nova linguagem.

LegacyRuntime.execute (script String);

Ser capaz de misturar códigos antigos e novos deve facilitar a transição.


11

O fato de você estar lidando com uma linguagem de script personalizada é irrelevante. Você está migrando um conjunto de scripts de um idioma para outro.

Existem 2 estratégias básicas:

1) Faça um grande esforço para converter todos os scripts antecipadamente (como um projeto)

2) Conforme você precisar fazer alterações em scripts específicos, reescreva-os no novo idioma. Depois de algum tempo, quando houver apenas alguns scripts restantes no idioma original, prossiga com a análise de um projeto para finalizá-los. *

De qualquer maneira, você precisa definir uma regra rígida e rápida: Nenhum novo código é escrito no idioma herdado.

* Você também pode definir uma regra sobre o quanto você pode editar antes de ter que reescrever tudo, mas é provável que isso seja abusado como um loop loop.


Acho que esqueci de mencionar que muitos scripts têm um objetivo, mas esse conhecimento desapareceu com seu criador quando eles deixaram a empresa.
Newtopian

1
Isso não muda nada ... Você precisará entender o código em algum momento. E você precisará do código Alterar em algum momento também. (A não ser, é claro, ninguém da equipe planeja estar por perto para isso :-) #
919 idiotas

1
Com uma estratégia muito simples, será menos provável que haja brechas a serem abusadas. Como uma adição à estratégia dos idiotas, eu tentaria colocá-los todos no controle de versão antes de fazer qualquer coisa.
refro

@refro Concordo com você, mas infelizmente seria quase impossível. Provavelmente, há uma dúzia de formatos de armazenamento diferentes para esses scripts e nenhum é muito compatível com SCM. O script geralmente é apresentado como um blob de base 64 que precisa ser carregado no editor compatível. Mas, principalmente, é porque os scripts podem ser editados diretamente pelos clientes e armazenados localmente em seus bancos de dados. Existe uma grande quantidade (suspeita) de scripts que nem sabemos que existem. que disse que o idioma é tão difícil de trabalhar, duvido que muitos clientes tenham investido muito nele.
Newtopian

5

Eu tive essa experiência.

Minha abordagem foi a engenharia reversa da implementação da linguagem, derivando uma especificação mais ou menos formal para sua sintaxe e semântica (imagine desconstruir um BNF a partir de um analisador manuscrito no Fortran77, com vários milhares de palavras-chave). Em seguida, implementei um compilador para esse idioma, traduzindo-o em um código idiomático de Lua (mesmo preservando a maioria dos comentários).

Você pode escolher qualquer linguagem de script popular adequada ou implementar sua própria DSL melhor projetada. O compilador pode ser usado como uma camada de conversão transparente (mantendo intactos os scripts herdados) ou para reescrever os scripts para uma melhor manutenção adicional.

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.