by Legacy Code o código heredado: ¿qué es?, ¿cómo se lo maneja?, ¿por qué representa un reto?
Se lo define como el desarrollo anterior que ha llegado a nuestras manos del que no se tienen buenas referencias. Líneas que escribió alguien más que ya no está en el proyecto o que dejó el equipo hace tiempo. En general código que a la vista de un tercero es perfectible en cuanto a tamaño y eficiencia.
El caso es que el código es funcional en parte y la reparación de errores en él «sin un buen tratamiento», ocupa tiempo valioso para pruebas y actualización.
El comportamiento de tu equipo de desarrollo puede dejar ver algunos síntomas de la presencia de código heredado conflictivo como estos:
- Los miembros de tu equipo eluden el trabajar con el código
- Hay demoras en la actualización de un desarrollo en particular
- Elevada presencia de errores en el análisis de cada iteración
- Tiempos de prueba elevados muy por encima de los estimados
Plantear la renovación completa de la jerarquía de clases del código no siempre es posible ya que existen desarrollos de gran magnitud con legacy code presente solamente en uno que otro módulo.
Identificando el problema
La tarea entonces es dedicarse a identificar la presencia del código heredado y utilizar las técnicas que contribuyen a su delimitación, mejora o eliminación según sea el caso.
Para dar con él problema podemos empezar con los reportes de resultados de calidad de nuestros usuarios internos y externos.
Luego, el servirnos de una buena guía nos ayudará en el proceso. Para este caso podemos partir de las recomendaciones de Martin Fowler en «Refactoring: Improving the Design of Existing Code» (Refactorización: Mejorando el Diseño del Código Existente)
Martin Fowler sugiere la implementación de pequeños cambios que por sí solos no implican un gran impacto en la aplicación pero que al realizarlos de manera incremental ordenada y sistemática conducen a cambios significativos en la calidad del código.
En su sitio web Refactoring.com podemos encontrar un Catálogo de Refactorizaciones cada uno con su explicación y diagramas en detalle, producto de su experiencia mejorando la eficiencia del código, su tamaño y limpieza.
Reconocer los olores
El autor llama «Olores» a los tipos de Legacy Code que se pueden reconocer fácilmente.
Basados en el trabajo de Fowler, en Source Making, un sitio dedicado a las buenas prácticas en arquitectura de software, tenemos también un Catálogo de Olores con explicaciones por categoría y una buena síntesis de los conceptos para cada caso.
Las categorías de olores son:
- Bloaters («Hediondos» en español)
- Abusadores de Orientación a Objetos
- Preventores del Cambio
- Eliminables y
- Acopladores
Los olores dentro de cada categoría se describen claramente, se recomienda un tratamiento y se refieren conclusiones.
Muy recomendable lectura de un libro que, publicado originalmente en 2002, mantiene su vigencia gracias a los valiosos resultados que han obtenido diversos grupos de desarrollo desde su publicación hasta ahora.
La refactorización se puede hacer a varios niveles. Una vez que se hayan eliminado los malos olores de primer orden se eleva el proceso a conseguir mejoras en el diseño mediante el uso de patrones de arquitectura. Source Making también trata el tema aquí. Adicionalmente, se puede encontrar un enfoque más amplio sobre los patrones de diseño en el libro Head First Design Patterns.
El tema da para más, así que extenderemos detalles sobre herramientas y prácticas de Refactorización en siguientes artículos.
