Estrategias de migración para desaprobar el lenguaje de scripting interno

8

Tenemos un lenguaje de script que utilizamos internamente para muchas cosas. Comenzó como simples declaraciones de evaluación para que las etiquetas dinámicas se convirtieran en un lenguaje completo de Turing utilizado de manera generalizada en todo nuestro sistema.

El problema es que nunca fue diseñado para esto y se nota. El entorno de desarrollo es anémico, las secuencias de comandos producidas no son verificables y aún hoy en día no existe una definición formal del lenguaje.

Un sentimiento cada vez mayor entre los usuarios del lenguaje siente que ha hecho su trabajo y es hora de dejarlo ir, pero nos enfrentamos a un desafío difícil de migrar la base de código existente a cualquier solución nueva que se idee. Este mismo argumento se usa contra la idea de migrar.

¿Alguna vez has enfrentado una situación similar? y si es así, ¿qué estrategias usaste para detener el uso de lo viejo y promover lo nuevo?

Una última cosa (gracias, Morons ) es que muchos de estos scripts no están documentados y su propósito original se pierde aunque todavía están en uso activo. Los scripts también se usan en los sitios de los clientes para personalizar el sistema, por lo que tenemos literalmente miles de estos scripts, una gran parte de los cuales no está bajo el control de la fuente ni ningún mecanismo de control de versiones para el caso.

Respuesta aceptada

Difícil elección es esta. Todas las respuestas fueron buenas y un buen consejo, aunque creo que las mejores mentiras son un híbrido de las de Moron y Oliver.

Terminé aceptando Oliver's porque es la respuesta que tiene la mejor oportunidad de ser aceptado más arriba (¡ja! ¡Política!). Empaquetar el antiguo entorno de secuencias de comandos en una declaración invocable que se puede integrar en el nuevo entorno proporcionaría una ruta de actualización rápida y fácil.

Una vez hecho esto, podemos controlar una mejor creación de nuevos scripts al mostrar advertencias o no permitir que se editen o creen scripts antiguos completos que obliguen a ir con el nuevo lenguaje.

¡Gracias a todos por su aporte!

— Newtopian
fuente

44

Cuando leí "una última cosa (gracias Morons)", pensé que estabas comentando sobre la inteligencia del diseñador original.

— Kyle Hodgson

2

:-D no, aunque me sentí muy extraña escribiéndolo y dudé por un momento. Por otra parte, eligió el nombre, así que supongo que está bien.

— Newtopian

1

¡¡Está bien!! ......

— Morons

5

Otro enfoque sería transferir el tiempo de ejecución de las secuencias de comandos al nuevo lenguaje de secuencias de comandos de elección y proporcionar formas de ejecutar secuencias de comandos heredadas dentro del nuevo lenguaje.

LegacyRuntime.execute (secuencia de comandos de secuencia);

Ser capaz de mezclar código antiguo y nuevo debería facilitar la transición.

— OliverS
fuente

11

El hecho de que esté tratando con un lenguaje de script personalizado es irrelevante. Está migrando un conjunto de scripts de un idioma a otro.

Hay 2 estrategias básicas:

1) Haga un gran esfuerzo para convertir todos los scripts por adelantado (como un proyecto)

2) Como necesita realizar cambios en secuencias de comandos particulares, vuelva a escribirlas en el nuevo idioma. Después de un tiempo, cuando solo quedan unos pocos scripts en el idioma original, siga adelante con un proyecto para terminarlos. * *

De cualquier manera, debe establecer una regla rígida y rápida: no hay ningún código nuevo escrito en el lenguaje heredado.

* También puede establecer una regla sobre cuánto se le permite editar antes de tener que volver a escribir todo, pero es probable que se abuse de él como un agujero de bucle.

— Imbéciles
fuente

Supongo que olvidé mencionar que muchos de los scripts tienen un propósito, pero ese conocimiento desapareció con su creador cuando dejaron la compañía.

— Newtopian

1

Esto no cambia nada ... Necesitará comprender el código en algún momento. Y también necesitará Cambiar el código en algún momento. (A menos que, por supuesto, nadie en el equipo planee estar cerca para eso :-)

— Morons

1

Con una estrategia muy simple, será menos probable que se expliquen las lagunas. Como una adición a la estrategia de Morons, trataría de ponerlos a todos en control de versiones antes de hacer nada.

— refro

@refro Estoy de acuerdo contigo, pero desafortunadamente sería casi imposible. Probablemente hay una docena de formatos de almacenamiento diferentes para estos scripts y ninguno es muy compatible con SCM. El script a menudo se presenta como un blob de base 64 que debe cargarse en el editor compatible. Pero principalmente se debe a que los clientes pueden editar los scripts directamente y se almacenan localmente en su base de datos. Hay una gran cantidad (sospechada) de scripts que ni siquiera sabemos que existen. Dicho esto, el lenguaje es tan difícil de trabajar que dudo que muchos clientes hayan invertido mucho en él.

— Newtopian

5

Tuve tal experiencia.

Mi enfoque consistía en aplicar ingeniería inversa a la implementación del lenguaje, derivando una especificación más o menos formal para su sintaxis y semántica (imagine deconstruir un BNF a partir de un analizador manuscrito en Fortran77, con varios miles de palabras clave). Luego implementé un compilador para este lenguaje, traduciéndolo a un código idiomático de Lua (incluso conservando la mayoría de los comentarios).

Puede elegir cualquier lenguaje de script popular adecuado o implementar su propio DSL mejor diseñado. El compilador podría usarse como una capa de traducción transparente (manteniendo intactos los scripts heredados) o para reescribir los scripts para un mejor mantenimiento adicional.

— SK-logic
fuente