¡Hola, Habr! En el Luxoft TechFest celebrado el 28 de enero, Mikhail Zankovich, líder del equipo senior de Luxoft , habló sobre aplicaciones con herencia severa. Hoy comparte pensamientos adicionales implicados en el contenido de este informe, lo que provocó una discusión bastante acalorada durante la reunión.
¿Qué emociones y asociaciones evoca en ti la frase "Tenemos un proyecto heredado"? La mayoría de las veces: falta de estructura, caos, toneladas de código indocumentado, horror, anarquía arquitectónica, disgusto, un mar de muletas, ¡tienes que correr! Mis emociones: “¡Oh! Finalmente, algo interesante. ¡Hagamos que funcione! " Sospecho que esta es una reacción muy inusual.
En este artículo intentaré revelar una ideología diferente de trabajar con el legado. Vamos a designarlo como "restauración de software". No tengo la intención de cambiar tu actitud hacia Legacy, pero si logras al menos sembrar una pizca de duda de que Legacy puede ser interesante, me alegraré.
Legado típico
¿Qué es Legacy? En mi experiencia, puede crear la siguiente lista de verificación para el cumplimiento de productos heredados:
- .
.. , , .
- .
, black-box. . . - .
, . - .
. / ..
Todo esto lleva al hecho de que se vuelve cada vez más difícil mantener un proyecto de este tipo con cada lanzamiento, al igual que desarrollar nuevas funciones / nuevos requisitos. Cualquier cambio se convierte en ingeniería inversa con pruebas de regresión obligatorias, etc. Como resultado, el proyecto se vuelve costoso de mantener y se “congela” en su forma actual con la minimización de cualquier cambio.
Pero, ¿por qué aparecen los productos heredados?
Rara vez un equipo crea consciente y deliberadamente un producto de baja calidad. La mayoría de las veces esto es el resultado de oportunidades limitadas por la situación actual del proyecto.
No hay requisitos claros, no hay posibilidad de un diseño equilibrado de la funcionalidad de la aplicación.
Los requisitos en constante cambio, la formulación poco clara, los plazos de implementación ajustados, la deuda técnica en constante crecimiento son signos claros de procesos de desarrollo ágiles en un equipo que no ha podido adaptarse completamente a estos enfoques "ágiles". Y de "flexible" sólo "solicitudes cambiantes rápidamente de la empresa" funcionan.
Esto a menudo conduce a una mayor rotación dentro del equipo, lo que a su vez no tiene un efecto positivo en la calidad. Imagina que un nuevo especialista se incorpora al equipo, durante dos o tres meses solo profundiza en el proceso, luego durante un mes y medio o dos implementa algún tipo de funcionalidad y se prepara para dejar el proyecto. No le interesa un producto de calidad, documentación completa de su parte, transferencia de conocimientos a compañeros, etc. La experiencia está borrosa.
En algún momento, se toma una decisión fatal: es más fácil reemplazar / apagar que acompañar. Y el proyecto entra en la fase de “bajo mantenimiento”, cuando se apoya sobre una base sobrante, tratando de minimizar los cambios, creando “muletas” adicionales que implementan nuevas solicitudes de manera rápida pero pobre. ¿Por qué alta calidad? El producto cambiará. En este modo, el producto puede sobrevivir durante muchos años, llenándose de "muletas" y volviéndose más monstruoso.
Resumiendo todo lo anterior, se pueden identificar las siguientes razones principales para la aparición de productos heredados:
- plazos ajustados para la implementación de la funcionalidad;
- falta de requisitos claros / requisitos que cambian intensamente;
- mayor rotación dentro del equipo;
- planificación inadecuada del ciclo de vida.
Agregamos aquí el nivel de desarrollo profesional de los especialistas en este momento. Abra su proyecto hace cinco o diez años. Estoy seguro de que ahora puede encontrar fácilmente elementos que implementaría de manera diferente.
Entonces, tomamos como axioma: "el código no se crea intrínsecamente malo". Esto significa que cualquier producto tuvo algún tipo de idea. Y si el código entró en producción, funcionó y satisfizo las necesidades de la empresa en ese momento.
Enfoque de escolta
Las tareas por parte de los clientes son bastante simples: mantener el legado en funcionamiento sin interrumpir los procesos comerciales actuales (algunos de los cuales generalmente son desconocidos para nadie), mientras se desarrolla la funcionalidad de acuerdo con los nuevos requisitos de acuerdo con el presupuesto, que es muy probable que sea limitado.
El enfoque típico de un equipo que se embarca en un proyecto es continuar empeorando las cosas de manera lenta pero segura. No toques demasiado, cambia solo lo que se te pide y solo cuando se te pide. Si el módulo funciona, pero requiere modificación de la lógica, déjelo y no lo toque, es mejor crear otro, pero con la lógica necesaria. El caos crece, la aplicación se vuelve más complicada.
El enfoque del restaurador
El enfoque de un restaurador de software es averiguar qué tipo de mecanismo se encuentra frente a él. Cuál fue la idea principal detrás de sus creadores. Intente cortar todo lo que sea innecesario y conserve lo mejor. Si cambia la estructura existente, entonces es extremadamente cuidadoso y atento a los detalles. Ningún detalle que afecte al sistema debe ocultarse a la vista del restaurador. Los cambios introducidos se resuelven primero de acuerdo con la lógica de mantenimiento y luego se realiza un análisis para determinar la posibilidad de implementar una solución completa.
Este es un trabajo difícil y que requiere mucho tiempo. No todos los desarrolladores están dispuestos, y lo más importante, son realmente capaces de realizar una restauración. Los requisitos para el nivel del restaurador son un orden de magnitud más alto que para un desarrollador ordinario. Sin experiencia en proyectos reales, sin entender cómo se pueden desarrollar los sistemas, sin colisión no solo con los mejores enfoques en la práctica, sino también con implementaciones claramente fallidas, no tiene sentido restaurar.
En lugar del típico primer impulso: “¡Sí, son muletas! ¡Todo necesita ser reescrito aquí! " - un verdadero restaurador hará la pregunta “¿Por qué se hizo de esta manera? ¿Cómo exactamente se planeó usarlo? " Y solo después de asegurarse de que no existían requisitos previos obvios para la creación de dicho código, el restaurador puede exclamar: “¡Sí, estas son muletas! ¡Todo debe ser reescrito aquí! ”, Y con una sensación de logro, realmente puede romper el crecimiento innecesario en el marco osificado del software, haciendo que el objeto de restauración sea mejor y de mayor calidad.
Pero esto rara vez ocurre, aunque da un placer indescriptible al restaurador. La mayoría de las veces, debe desenredar la maraña de dependencias entre diferentes módulos. No es raro que los hilos se extiendan mucho más allá del área de responsabilidad del componente que se desmonta (y, a veces, del sistema). Y todas estas complejidades de las relaciones de los módulos deben tenerse en cuenta al restaurar.
Por lo tanto, el restaurador de software trabaja en la intersección del desarrollo, la arquitectura, el análisis empresarial, las pruebas y la medicina. Y es difícil decir qué habilidades de las áreas designadas son las más prioritarias. Debe haber un cierto equilibrio entre ellos, aderezado con un deseo sincero de participar en la restauración. ¿Qué tiene que ver la medicina con esto? Por tanto, el principio fundamental del restaurador es "primum non nocere": en primer lugar, no hacer daño.
En realidad, este enfoque se considerará más a fondo en ejemplos específicos, desmontando y restaurando gradualmente el legado típico heredado de los propietarios técnicos anteriores de los sistemas. Y con ejemplos específicos, veamos por qué todas las habilidades anteriores son importantes.
Restauración del almacén de datos
¿Qué almacena el sistema?
Al aterrizar en un nuevo proyecto, el restaurador prestará atención a los objetos procesados por el sistema. Para sumergirse completamente en los flujos comerciales y el código fuente, especialmente en ausencia de documentación normal, llevará al menos varios meses.
Una de las primeras tareas de un restaurador es evaluar la efectividad de la bóveda. ¿Puede mejorar algo sin depender de la comprensión de los procesos comerciales? Un problema típico de cualquier almacén de datos está relacionado principalmente con el volumen de estos mismos datos. Cuanto mayor sea el volumen, mayor será el costo de propiedad del sistema.
El segundo punto de dolor es el crecimiento de este mismo volumen, que en primer lugar afecta negativamente el rendimiento del sistema. Lo más probable es que ya existan algunas prácticas para retener información en el sistema, pero ¿qué tan efectivas son?
Todas las prácticas consideradas aquí son más aplicables a los RDBMS clásicos, pero el enfoque no es muy diferente para las soluciones sin sql.
Una de las principales tácticas del restaurador en esta dirección es la creación de monitoreo de objetos de almacenamiento de información. En el caso del DBMS clásico, monitorización de tablas.
Se necesita un marco que permita que los metadatos del sistema recopilen datos periódicamente sobre dos parámetros triviales: la cantidad de datos y la cantidad de elementos en cada tabla. La frecuencia deberá seleccionarse manualmente (más sobre esto a continuación), en función de las características del sistema. Un período de puesta en marcha típico de 24 horas es suficiente para un análisis básico.
Analizar datos
¿Qué hacer con los datos? ¿Qué buscar? El primer momento es identificar los "objetos más pesados". En la práctica, la regla estándar 20/80 funciona: no más del 20 por ciento de los objetos utilizarán más del 80 por ciento del espacio. Esto le permite reducir significativamente el área de análisis en la primera etapa.
Cuanto más tiempo y más detalladamente se acumulan estas estadísticas, más claramente se refleja el comportamiento del sistema. La experiencia ha demostrado que el período recomendado es de al menos dos semanas. La idea principal es "enganchar" los días / períodos no laborables dentro de los cuales se implementan con mayor frecuencia los mecanismos de limpieza y archivo de información.
Entonces, ¿el marco está escrito y el restaurador espera los resultados durante dos semanas? Por supuesto que no. No lucha contra la ideología del restaurador. Con la primera parte de datos en la mano, puede hacer un análisis básico. Es decir, para ver la relación entre el espacio ocupado y el número de objetos almacenados (filas). Cuanto mayor sea este valor, más probable será que los campos BLOB se almacenen aquí. Y precisamente estas tablas y campos se convierten en objeto de investigación y análisis para el restaurador.
Preguntas clave: ¿Con qué frecuencia los procesos comerciales acceden realmente a estos objetos? El propietario del sistema, el equipo existente, puede arrojar algo de luz sobre estos puntos. Y de repente (y en la práctica muy a menudo) resulta que dichos campos almacenan información que no es importante para el negocio: volcados de objetos / mensajes para que los analice el equipo de desarrollo, comentarios de los usuarios que solo se muestran al crear un pedido, etc.
El siguiente paso: si los datos no se utilizan con frecuencia o no tienen un valor comercial claro, ¿por qué no trasladarlos al archivo? Al mismo tiempo, un enfoque cardinal para dividir una tabla monolítica en partes, mover blobs a un medio más barato / más lento, pero al mismo tiempo preservar la interfaz original de la tabla (el punto principal es que no hay información confiable sobre todos procesos que acceden a esta información, lo que significa que los cambios no deberían dañarlos) - puede ser un problema técnico bastante interesante y complejo.
Una tarea menos interesante pero igualmente útil es utilizar el sistema de almacenamiento de datos integrado para archivar los valores de ciertos campos. Por ejemplo, Sybase ASE tiene la función ASE_Compression, Mongo DB le permite establecer opciones de compresión para colecciones, etc. Casi cualquier sistema de almacenamiento de datos tiene la opción de compresión de datos adicional "bajo el capó". La funcionalidad funcionará de forma transparente para sistemas externos y no requerirá cambios drásticos. En la práctica (especialmente en sistemas heredados), estas opciones de compresión de datos no se utilizan de forma predeterminada.
Por supuesto, al aplicar la compresión, el restaurador debe evaluar primero el impacto del enfoque en el rendimiento y, para ello, deben elaborarse indicadores clave de rendimiento del sistema o, en casos extremos, deben estar presentes elementos de prueba de regresión.
En general, hay algo que hacer durante un par de semanas mientras se recopilan estadísticas completas sobre los objetos.
Grandes estadísticas: qué buscar
Habiendo recibido estadísticas durante un largo período de tiempo, el restaurador intenta averiguar qué está sucediendo con la dinámica del espacio utilizado. Todos los valores de una tabla / objeto se normalizan al original. Esto permitirá estimar con precisión el aumento relativo de datos e identificar los objetos que cambian más intensamente.
El perfil generado probablemente corresponderá a uno de los siguientes tipos:
Perfil 1 - valor constante. Lo más probable es que se trate de directorios estáticos y no es tan interesante trabajar con ellos. El enfoque de archivo descrito anteriormente se puede aplicar en función de la intensidad de uso del directorio.
Pequeñas fluctuaciones de volumen - perfil 2- Pueden hablar tanto de un libro de referencia como de una tabla operativa, en la que la lectura / escritura de datos es intensiva. Estos son los objetos más difíciles desde el punto de vista del restaurador, porque es necesario analizar su comportamiento con el mayor detalle posible. Es para estos objetos que tiene sentido aumentar la frecuencia de recopilación de información: no una vez al día, sino una vez por hora, una vez por minuto. El objetivo principal es rastrear el cambio de perfil con más detalle y comprender las dependencias de comportamiento.
Los perfiles 3 y 4 son de mayor interés. Perfil 3("Saw") establece claramente que esta tabla se limpia periódicamente. Pero la tendencia creciente - cada vez después de la limpieza, el volumen final es ligeramente mayor que antes - habla de la ineficacia de los mecanismos de limpieza existentes. Aquellos. durante un cierto período de tiempo, aparecen más datos en el sistema de los que se eliminan al final del período. Este puede ser un proceso comercial completamente normal, un aumento clásico en la carga del sistema.
Pero para el restaurador, esto es, ante todo, una señal: ¿existen condiciones para borrar información? Según la práctica, lo más probable es que algunas entidades, debido a las complejas condiciones de retención de datos en el sistema, permanezcan inmerecidamente para siempre en el almacenamiento. El objetivo del restaurador es identificar estas entidades y también incluirlas en actividades periódicas.
Si el perfil 3 degenera en un crecimiento constante, este es el primer competidor por un cuello de botella en el sistema. En primer lugar, no hay indicadores explícitos para el proceso de archivo y, en segundo lugar, se espera una degradación del rendimiento con el crecimiento de los datos.
Perfil 4- un ejemplo típico de una tabla de archivo con llenado periódico de datos. Tenga en cuenta que el crecimiento de la mesa ocurre solo en ciertos días. Es muy posible que se noten correlaciones con tablas del tercer perfil. Para las tablas de archivo, también es importante comprender el principio de su uso: ¿hay alguna llamada de los usuarios? ¿O es una historia para analizar? ¿O son datos para sistemas de informes? Dependiendo de las respuestas a estas preguntas, es muy posible que se tome la decisión de separar las tablas de archivo en un circuito separado, una base separada, una sección separada. Liberando así el espacio operativo.
¿Cómo funciona en la práctica?
En uno de los proyectos, se realizó un ejercicio similar en el primer mes y medio después de unirse al proyecto. Fueron los objetos del perfil No. 3 los que fueron el objetivo, y fueron encontrados. Aplicar las prácticas descritas (mejorar las condiciones de limpieza), eliminar datos que no se utilizaron dentro del sistema, etc. permitió reducir el volumen de espacio ocupado en más del 25%, así como detener el crecimiento intensivo del almacenamiento.
Como resultado, pudimos realizar los primeros cambios técnicos en el proyecto y presentar planes para mejorar la funcionalidad. El cliente quedó satisfecho con el resultado del equipo y se expandió de 3 a 9 desarrolladores. A lo largo del año continuamos con las investigaciones, se utilizaron los puntos de mejora en funcionalidad para dar soporte al sistema y sus características.
Se nos agregaron dos analistas, por lo que el equipo comenzó a participar en su propio desarrollo, no en el soporte, sino en la implementación de nuevas funciones comerciales. Ahora estamos desarrollando un nuevo sistema.
¿Para qué es todo esto?
Si ha leído hasta aquí, lo más probable es que esté buscando una respuesta a la pregunta: "¿Por qué es todo esto?" En primer lugar, la restauración es un proceso separado, no como desarrollo, no como soporte, sino combinándolos.
Este es un impulso separado para un especialista técnico: profundizar en la lógica de la persona que creó este producto, comprender su significado, limpiar el producto de cosas innecesarias y hacerlo aún mejor de lo que era. La aplicación parece una misión, con muchos misterios y giros de trama desconocidos.
No, no está creando desde cero, está restaurando un producto existente, pero quizás destruido por el tiempo. Entre otras cosas, el restaurador tiene la oportunidad única de bombear en cualquiera de las seis direcciones (vea la imagen de arriba), mientras tiene un producto real a mano como base de prueba. También se bombea un sentido de autocontrol, no para caer en el perfeccionismo técnico, sino para pensar y hacer solo los cambios que son necesarios para el sistema en términos de mejora de procesos.
Todo esto hace que trabajar con sistemas heredados sea emocionante e inusual. Pero la decisión final para restaurar o mantener es suya.
El informe de Mikhail Zankovich en Luxoft TechFest se puede ver aquí .
El autor del artículo es Mikhail ZankovichMikhailZankovich