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 sobre el que el equipo tenga conocimientos limitados.

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, es que no comprende cómo cambiarlo puede afectar la funcionalidad existente. Las brechas de conocimiento asociadas con el código heredado pueden convertirse en una barrera si está haciendo la transición a una nueva metodología de desarrollo, como ágil 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 no dejan espacio para mitigar resultados potencialmente problemáticos cuando se trata de código heredado. Es probable que intentar iterar rápidamente en un código que no comprende introduzca nuevos problemas.

La realidad es que estas técnicas son mucho más fáciles de aplicar a la hora de iniciar nuevos proyectos. Para proyectos que han existido por un tiempo, los equipos generalmente trabajan con sistemas que involucran código heredado. Es posible que los desarrolladores no sepan cómo funciona el código base existente, pero aún 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.

Por qué la deuda técnica importa (o no)

El juego de 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 los objetivos comerciales en función de lo que sucede en el mercado. Con el tiempo, acumulamos deudas técnicas.

¿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 al 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 tienen una gran deuda técnica en forma de poca capacidad de prueba, baja cobertura, código demasiado complejo, etc. La deuda técnica puede pesar la aplicación de prácticas de desarrollo de software más nuevas porque los equipos enfrentan constantemente la pregunta de si deben abordar 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 recursos significativos 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 planee cambiar. Pero no lo sabrá a menos que comience a tomar algunos pasos adicionales (lo abordaré 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 línea de base para un nuevo desarrollo. El código heredado ya está en el campo y supuestamente funciona, por lo que el objetivo es garantizar la calidad del nuevo código. Para cumplir con la política de cobertura, muchas organizaciones aumentan la cobertura del código heredado por cualquier medio necesario. 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 un código heredado que está bien cubierto, las métricas generales del proyecto pueden indicar si el nuevo desarrollo se está moviendo en la dirección correcta.

La razón fundamental de esta estrategia es sólida, pero el problema es que las organizaciones generan pruebas a ciegas para cumplir con su política de cobertura. Como resultado, el proyecto está cargado de pruebas imposibles de mantener que proporcionan una falsa sensación de calidad del software. Si no planea tocar el código o no le preocupa la capacidad de mantenimiento o la calidad de la prueba, puede usar una de las varias herramientas de generación de pruebas en el mercado que pueden ayudarlo a lograr este objetivo.

Cree pruebas de Java significativas y mantenibles

Para ser claros, no estoy abogando por generar pruebas a ciegas. En su lugar, 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 automático de creación de pruebas basado en el código existente. La suite de regresión resultante es significativa, mantenible y ampliable.

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 compilació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? Las métricas adicionales, como la complejidad, los comentarios, etc., pueden proporcionar una perspectiva sobre el estado de la calidad del software.

Parasoft proporciona una poderosa plataforma de análisis para capturar, correlacionar y reportar 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 las partes de la aplicación afectadas por el cambio.

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

2. Capturar 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 una suite de regresión de alta calidad no solo captura el comportamiento existente, sino que también impulsa la cobertura, que sirve como una red de seguridad para asegurarse de que los cambios no rompan la funcionalidad.

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

Es mejor ampliar la cobertura con pruebas significativas. Durante el análisis de la brecha de cobertura, Jtest identifica las pruebas existentes que se pueden clonar y mutar para llegar a partes del código no probadas. Se trabajó mucho para crear esas pruebas existentes, y la funcionalidad de clonar y mutar en Jtest aumenta el retorno de su inversión en la creación de pruebas.

Debe esforzarse por lograr el nivel más alto de cobertura posible, pero en la mayoría de los casos, lograr una cobertura del 100% en todo el código no es práctico. Discutiremos una técnica adicional que puede aplicar como red de seguridad para garantizar la cobertura del código modificado un poco más tarde.

Cuando tenga una buena cobertura desde una perspectiva funcional, puede comenzar a realizar cambios y modificar las pruebas a medida que avanza.

3. Mejore el código heredado aislado.

Con el comportamiento del sistema capturado, puede comenzar a corregir violaciones, abordar los RP o aplicar los cambios en los que desea enfocarse con un riesgo mínimo de romper la funcionalidad existente. Parasoft puede ayudarlo a administrar la deuda técnica existente y colocar datos, como violaciones de análisis estático, en flujos de trabajo apropiados donde se pueden volver a priorizar, suprimir o resolver fácilmente para mejorar la calidad general de la aplicación. Los cambios de construcción a construcción 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

Este proceso ayuda a garantizar que el alcance de los cambios no afecte negativamente 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 creamos tecnología que puede notificarle automáticamente cuando el código modificado (es decir, código nuevo o cambiado) no cumple con la política de cobertura.

Al analizar los cambios entre las compilaciones de línea de base especificadas, puede concentrarse y monitorear el cambio en todo el código base para asegurarse de que nada se escape por las grietas. Lograr una cobertura del 100% en todo el código no es práctico, 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.

Para concluir, el software del mundo se ejecuta en código que se ha transmitido de un equipo a otro. Lidiar con el 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 extender la funcionalidad, y los procesos y tecnologías que se utilizan aquí deberían ayudarlo a ganar la confianza para asumir casi cualquier base de código que se imponga a sus equipos.