Trabajar con código heredado y tres pasos para actualizarlo

Cuando se trata de código heredado, necesita una forma sostenible de gestionar el cambio. Trabajar con código heredado puede ser una barrera para Agile y DevOps, pero puede superar el desafío aprovechando las tecnologías adecuadas.

¿Qué es el código heredado?

Mucha gente usa el término "código heredado" para referirse simplemente al código antiguo. Pero "viejo" y "legado" significan cosas diferentes para diferentes personas. Aquí, estoy usando la definición de código heredado como cualquier código existente que ya no sea compatible o no esté actualizado, y el equipo tenga un conocimiento limitado al respecto.

El conocimiento sobre el código puede estar incompleto por varias razones, como:

• El equipo adquirió un proyecto de otra parte de la organización.
• El autor original dejó el equipo y se llevó el conocimiento sobre el código.
• La funcionalidad entregada por el código ya no es una prioridad comercial y se ha mantenido sin cambios, lo que resulta en el olvido de detalles sobre el código.

En cualquier caso, seamos claros: el código heredado es la regla, no la excepción. Gran parte de la infraestructura de software del mundo actual se ejecuta en código heredado. La pregunta es, entonces, ¿cómo mitigamos los riesgos asociados con el código heredado cuando necesitamos hacer un cambio? En esta publicación de blog, le daré algunas soluciones para trabajar de manera efectiva con código heredado.

El código heredado es una barrera para Agile y DevOps

El problema con el código heredado no es su antigüedad, sino que no se comprende cómo cambiarlo puede afectar la funcionalidad existente. Las lagunas de conocimiento asociadas con el código heredado pueden convertirse en una barrera si está realizando la transición a una nueva metodología de desarrollo, como Agile o DevOps.

Agile y DevOps se han convertido en las metodologías dominantes para la creación de software porque ayudan a los equipos a iterar y lanzar aplicaciones rápidamente tan pronto como las características mínimas comercializables estén listas. Los ciclos de desarrollo cortos y frecuentes son el sello distintivo de las metodologías de desarrollo iterativas, pero estos enfoques a menudo no dejan espacio para mitigar resultados potencialmente problemáticos cuando se trata de código heredado. Es probable que intentar iterar rápidamente código que no comprende introduzca nuevos problemas.

Mantenerse al día con los cambios en el código fuente es mucho más fácil al iniciar nuevos proyectos. Para proyectos que ya existen desde hace algún tiempo, los equipos suelen trabajar con sistemas que involucran código heredado. Es posible que los desarrolladores no sepan cómo funciona el código base existente, pero aun así deben corregir defectos o ampliar la funcionalidad sin introducir nuevos problemas. E incluso los cambios superficiales o aparentemente pequeños pueden tener un impacto significativo en la aplicación.

Mitigar la deuda técnica

El juego del desarrollo de software consiste en equilibrar constantemente la calidad del software, el tiempo de comercialización y el costo de desarrollo. En la mayoría de los casos, hacemos concesiones para lograr objetivos comerciales en función de lo que sucede en el mercado. Con el tiempo, acumulamos deuda técnica.

¿Qué es la deuda técnica?

Deuda técnica es el costo de mitigar el riesgo asociado con la implementación de una solución imperfecta para lograr su objetivo de tiempo de comercialización o costo de desarrollo. Por ejemplo, renunciar a las actualizaciones de una biblioteca porque hacerlo habría retrasado el lanzamiento representa una deuda técnica en forma de tiempo que llevará actualizar la biblioteca más adelante.

En muchos casos, las bases de código heredadas están cargadas de deuda técnica en forma de poca capacidad de prueba, baja cobertura, código demasiado complejo, etc. La deuda técnica puede afectar la aplicación de nuevas prácticas de desarrollo de software porque los equipos enfrentan constantemente la pregunta de si abordar o no la deuda.

¿Debería preocuparse por la deuda técnica?

Para ponerlo en perspectiva, cada aplicación tiene una deuda técnica y muchas organizaciones pueden invertir importantes recursos para pagarla sin obtener ningún beneficio sustancial. Al final del día, la decisión de invertir recursos para pagar la deuda técnica depende de qué partes de su aplicación planea cambiar. Pero no lo sabrás a menos que empieces a tomar algunas medidas adicionales. Hablaré de eso en un momento.

Aumento de la cobertura en el código heredado

Cuando las organizaciones heredan una base de código heredada con la que lidiar, a menudo adoptan una política de cobertura que les ayuda a crear una base para nuevos desarrollos. El código heredado ya está en el campo y supuestamente funcionando, por lo que la atención se centra en garantizar la calidad del código nuevo. Para cumplir con la política de cobertura, muchas organizaciones aumentan la cobertura del código heredado a través de la creación de muchas pruebas unitarias nuevas. La baja cobertura reduce las métricas generales, lo que dificulta medir con precisión la cobertura de su nuevo desarrollo. Si sabe que está trabajando con código heredado que está bien cubierto, las métricas generales del proyecto pueden indicar si el nuevo desarrollo avanza en la dirección correcta.

El fundamento subyacente de esta estrategia es sólido, pero el problema es que las organizaciones generalmente no tienen tiempo para crear pruebas unitarias de buena calidad para cubrir esas brechas. Debería haber una mejor manera de manejar el código heredado.

Cree pruebas de Java significativas y mantenibles

Utilice una herramienta que le ayude a crear rápidamente pruebas significativas para cubrir su código heredado de Java. Prueba J de Parasoft proporciona una interfaz de apuntar y hacer clic que brinda a los desarrolladores un proceso de creación de pruebas automática basado en el código existente. El conjunto de regresión resultante es significativo, mantenible y extensible. Los clientes informan que ahorraron más del 50 % de sus esfuerzos de desarrollo para crear pruebas para su código heredado.

Los 3 pasos para actualizar su código heredado

En lugar de intentar trabajar en el nivel macro, cree una línea de base y reduzca el alcance de sus actividades de calidad a las áreas de código afectadas por los cambios planificados. Después de tomar medidas para evaluar el alcance y el estado del código, debe crear pruebas que capturen el comportamiento actual para que el equipo pueda comprender cómo los cambios pueden afectar la funcionalidad existente.

Luego, puede aprovechar una variedad de tecnologías que lo ayudan a recopilar análisis a medida que refactoriza el código heredado y garantizar que su inversión en cambios de código mejore la seguridad y la confiabilidad de los sistemas heredados.

1. Defina su alcance

Comprender cómo los cambios afectan el comportamiento del sistema requiere al menos un punto de datos. Comience eligiendo una construcción de referencia y comience a realizar un seguimiento de las métricas en el futuro. Establezca su alcance y observe tres características del código heredado.

• ¿Cuántas infracciones de análisis estático tiene y qué tan graves son? Debe comprender cuántos defectos potenciales están integrados en el código.
• ¿Cuál es su cobertura de prueba actual? La baja cobertura representa un riesgo potencial asociado con el cambio.
• ¿Cuánta limpieza será necesaria? Métricas adicionales, como la complejidad, los comentarios y similares, pueden proporcionar una perspectiva sobre el estado de la calidad del software.

Parasoft proporciona una poderosa plataforma de análisis para capturar, correlacionar y la presentación de informes violaciones de análisis de código, resultados de pruebas, análisis de cobertura y otros datos de calidad del software. La plataforma va más allá de los informes estáticos. También aplica análisis adicionales para ayudarlo a identificar partes de la aplicación afectadas por el cambio.

Puede identificar un conjunto específico de archivos o directorios y la cobertura del alcance, las infracciones del análisis estático y los datos de métricas de esos recursos específicos. Esta información le ayuda a crear una línea de base para áreas del código base antes de realizar cambios dentro de esas partes del código.

2. Capturar el comportamiento

Armado con un punto de datos inicial, el siguiente paso es comenzar a capturar el comportamiento actual del sistema mediante la creación de pruebas. La creación de un conjunto de regresión de alta calidad captura el comportamiento existente y crea una red de seguridad para garantizar que los cambios no afecten la funcionalidad.

Parasoft Jtest es ideal para esta tarea porque le permite crear una línea de base de pruebas JUnit de forma masiva, incluidas aserciones, basadas en el código existente. Jtest también incluye la capacidad de crear pruebas que accedan directamente a métodos privados cuando el código heredado no se escribió originalmente teniendo en cuenta la capacidad de prueba.

Es mejor ampliar la cobertura con pruebas significativas. Jtest puede crear pruebas unitarias solo para las partes descubiertas del código, evitando pruebas redundantes para el código que ya tiene algunas pruebas unitarias.

Parasoft Jtest también se puede integrar con los proveedores OpenAI o Azure OpenAI, lo que permite a los desarrolladores aumentar aún más sus pruebas mediante la entrada de indicaciones en lenguaje natural diseñadas por el usuario que describen cómo se deben refactorizar los casos de prueba. Esto proporciona opciones de personalización flexibles para los desarrolladores que buscan modificar rápidamente Casos de prueba de manera específica y pertinente a los requisitos de su organización.

Debe esforzarse por lograr el mayor nivel de cobertura posible, pero en la mayoría de los casos no es práctico lograr una cobertura del 100 % en todo el código base. Continúe leyendo para conocer una técnica adicional que puede aplicar como red de seguridad para garantizar la cobertura del código modificado.
Cuando tenga una buena cobertura desde una perspectiva funcional, puede comenzar a realizar cambios y modificar las pruebas a medida que avanza.

3. Mejorar el código heredado aislado

Una vez capturado el comportamiento del sistema, puede comenzar a corregir infracciones, abordar las relaciones públicas o aplicar los cambios en los que desea centrarse con un riesgo mínimo de alterar la funcionalidad existente. Parasoft puede ayudarte gestionar la deuda técnica existente y colocar datos, como violaciones de análisis estáticos, en flujos de trabajo apropiados donde se puedan volver a priorizar, suprimir o resolver fácilmente para mejorar la calidad general de la aplicación. Los cambios de una compilación a otra también deben monitorearse como parte del proceso continuo, para garantizar que la calidad del software no empeore.

El mejor momento para abordar la deuda técnica en el código heredado es a medida que realiza cambios. Los datos reportados deben incluirse en la información estadística general sobre el proyecto. Es posible que la deuda técnica no tenga un impacto inmediato en la aplicación, pero debe aplicar las mejores prácticas para contenerla y administrarla de manera sistemática. Refactorizar el código heredado cada vez que necesite realizar cambios lo ayuda a reducir gradualmente la deuda.

Garantía de cobertura en el código modificado

El proceso que hemos estado analizando garantiza que el alcance de los cambios no afecte negativamente a la funcionalidad existente, pero también debe asegurarse de que el equipo siga las buenas prácticas en el futuro. Continuar manteniendo un alto nivel de cobertura y escribir o actualizar pruebas a medida que el código evoluciona requiere aceptación a nivel cultural. Es por eso que Parasoft desarrolló una tecnología que le notifica automáticamente cuando el código modificado, nuevo o modificado, no cumple con la política de cobertura.

Al analizar los cambios entre las compilaciones de referencia especificadas, puede concentrarse y monitorear los cambios en todo el código base para asegurarse de que nada se escape. Es posible que no sea práctico lograr una cobertura del 100 % en todo el código base, pero al monitorear la cobertura del código modificado, el equipo puede concentrarse en las partes del código en las que se está trabajando activamente y tener la confianza de que todos los cambios se prueban.

En conclusión: trabajar con código heredado

El software del mundo se ejecuta con código que se ha transmitido de equipo a equipo. Tratar con código heredado es una realidad cotidiana. Las lagunas en el conocimiento sobre el código representan riesgos potenciales a medida que los desarrolladores realizan cambios para mantener o ampliar la funcionalidad, y los procesos y tecnologías descritos aquí deberían ayudarlo a ganar la confianza para asumir casi cualquier base de código que se imponga a sus equipos.