Header Ads Widget

Ticker

6/recent/ticker-posts

Los placeres de la remodelación

En una publicación anterior sobre migración , miré diferentes formas de tomar una base de código y convertirla para una nueva arquitectura. Los métodos funcionan mejor cuando el lenguaje se mantiene igual, aunque la última idea es tomar el código original en pequeños fragmentos y reelaborar esos fragmentos como componentes de la nueva solución probablemente se podría hacer en varios idiomas.

Sin embargo, una cosa a considerar es si la reestructuración mejora el software. ¿Por qué deberíamos cambiar de plataforma?

  • La plataforma existente ya no es compatible, por ejemplo, un antiguo sistema operativo o tiempo de ejecución
  • La plataforma existente tiene un gran riesgo de seguridad, por ejemplo, servicios no seguros o lugar en la red.
  • El costo de ejecutar un componente es alto
  • La confiabilidad es baja
  • Escalabilidad
  • Estrategia del centro de datos
  • Dificultad de mantenimiento

En general, es difícil argumentar en contra de la idea de que una pieza de software empresarial, actualmente implementada de una manera / entorno engorrosa, no sería mejor como una aplicación nativa de la nube que se ejecuta de forma económica a escala en la nube.

Discutamos contra eso

Un proyecto de migración mal pensado podría ser como encontrar algunos tornillos sueltos en un motor y, en lugar de repararlos, comprar una flota de taxis.

El aparente ahorro de costes de la migración a la nube siempre debe compararse con el riesgo y el coste de realizar el cambio.

En pocas palabras, no puede ser solo el costo lo que nos motiva a realizar una migración a la nube. He escuchado números como este componente es $ 10k / mes más barato de ejecutar ahora . Pero en un proyecto que cuesta, digamos $ 1 millón , son muchos meses antes de que recupere el dinero. (Son 8,3 años para aquellas personas que no se molestan en calcularlo)

De manera similar, el mayor riesgo con cualquier cambio de plataforma proviene de si está realmente claro qué debe hacer el software y qué tan bien podemos probar que, en su nueva forma, está obteniendo resultados equivalentes para el negocio.

Toda la mala ingeniería de software que hace que no nos guste el original puede amplificarse mediante un esfuerzo de reestructuración.

La arquitectura no arregla el proceso

En el centro de cualquier esfuerzo de reestructuración hay una pregunta sobre las necesidades futuras del proceso empresarial para el que se construyó originalmente el componente.

Levantar y cambiar el código tiene el efecto de repetir las fallas del proceso original, posiblemente con errores de transcripción adicionales.

Por lo tanto, el objetivo debe ser revisar el proceso de avance y buscar hacerlo más ágil y apropiado para la organización. Esto debe hacerse dentro del alcance del esfuerzo de ingeniería y no convertirse en una gran barrera de entrada para el producto. No hay razón para reinventar el mundo entero, pero no hay razón para creer que crear una réplica del original sea una buena idea.

El patrón original puede no ajustarse a la arquitectura futura

Parte del problema con la reestructuración es que la plataforma de destino puede no estar de acuerdo con el paradigma del componente original. Esto puede llevar a un híbrido atroz.

El híbrido atroz:

  • Parece la arquitectura heredada, pero se ejecuta en un nuevo entorno
  • No funciona como debería en el nuevo entorno, debido al legado
  • Tiene todos los errores del legado
  • Además de algunos errores introducidos al migrar
  • Es difícil de mantener porque no es familiar para todos.

Cualquier proyecto que comience con la frase simplemente levantemos y cambiemos corre el riesgo de llegar a esto. Intercambiar componentes similares por similares es atractivo y, con frecuencia, parece funcionar, pero no necesariamente coloca el software en el estado más deseable.

El estado más deseable para el software es que sea delgado, efectivo y con el nivel más bajo de complejidad. Debería parecer que fue diseñado así intencionalmente.

Romper el ciclo de elevación y cambio

Si bien en el nivel micro, el levantamiento y el cambio pueden ser apropiados, por ejemplo para algoritmos o estructuras de datos, en un nivel superior, existen otros procesos de pensamiento que pueden ayudar:

  • En el nuevo mundo, ¿cuál es el núcleo del proceso empresarial?
  • ¿Podemos migrar de forma incremental?
  • Si migramos de forma incremental, ¿podemos liberarlos de forma incremental?
  • ¿Necesitamos todo el conjunto de funciones original?
  • ¿Hay alguna simplificación que podamos hacer a los flujos?
  • ¿Podemos evitar patrones de diseño complejos, innecesarios o pasados ​​de moda?
  • ¿Podemos acercarnos a los datos de origen?
  • ¿Podemos acercar la salida al destino previsto?

La cuestión fundamental y más difícil de todas será averiguar cómo validar que el nuevo software hace el trabajo previsto. Esto puede implicar especificaciones de ingeniería inversa, pruebas o conjuntos de datos de ejemplo con respuestas esperadas.

Simplemente reescribir algo de código nunca es el problema central con un ejercicio de cambio de plataforma. Cualquier proyecto de cambio de plataforma definido en términos de código correrá el riesgo de perder el punto por completo.

Publicar un comentario

0 Comentarios