Antipatrones de desarrollo de software: Lava Flow

También conocido como Dead Code, el antipatrón Lava Flow es comúnmente encontrado en sistemas que fueron originalmente una investigación pero terminaron en el producto final. Se caracteriza porque al igual que la lava, "fluye" de las versiones anteriores de desarrollo esparcidos a lo largo del código, el cual ahora se ha endurecido como el basalto, inamovible, generalmente un masa inútil de código de la que nadie puede recordar mucho.

Este es el resultado de los primeros tiempos de desarrollo cuando, mientras se investigaba, los desarrolladores intentaban muchas formas de cumplir con los requerimientos, típicamente en una carrera para algún tipo de demostración, echando al viento las buenas prácticas de diseño y sacrificando la documentación.

El resultado son demasiados fragmentos de código, caprichosas variables de clase y procesos que no están claramente relacionados al resto del sistema. De hecho, estos flujos son a menudo tan complicados en apariencia y su semejanza al código spaghetti que hasta parecen importantes, pero nadie puede realmente explicar qué hacen o por qué existen.

A veces, un viejo desarrollador ermitaño puede recordar ciertos detalles, pero típicamente, todos han decidido "dejar las cosas como estaban" hasta que el código en cuestión "realmente no hace daño, actualmente puede ser crítico y no se dispone del tiempo para lidiar con él".

Aunque puede ser divertido dividir estos flujos y estudiar su "antropología", usualmente no hay tiempo suficiente en la agenda para semejantes "divagaciones". En cambio, los desarrolladores por lo general toman una ruta conveniente y trabajan pulcramente alrededor de él.

Este antipatrón es, de cualquier manera, increíblemente común en innovadores departamentos de diseño, en donde las pruebas de código conceptual o prototipo, son rápidamente movidos a producción. Es un diseño pobre por muchas razones importantes:

• Lava Flowsson caros de analizar, verificar y probar (test). Todo ese esfuerzo se gasta completamente en vano y es una absoluta pérdida. En la práctica, la verificación y las pruebas son raramente posibles.
• El código Lava Flow puede ser costoso al cargar en memoria, perdiendo importante recursos e impactando en el rendimiento.
• Como con muchos antipatrones, se pierde muchas de las ventajas inherentes de un diseño orientado a objetos. En este caso, se pierde la habilidad de aprovechar la modularización y reutilización sin más proliferación de "burbujas" del Lava Flow.

Síntomas y concecuencias

• Variables y fragmentos de código en el sistema frecuentemente injustificables.
• Segmentos complejos sin documentar, funciones en apariencia importantes o clases que no se relacionan claramente a la arquitectura del sistema.
• "Evlución" muy imprecisa de la arquitectura del sistema.
• Bloques enteros de código comentado sin explicación o documentación.
• Muchas áreas de código "a ser reemplazadas".
• Código sin usar (muerto), simplemente dejado allí.
• Interfaces sin usar, inexplicables u obsoletas en las cabeceras de clases.
• Si el código Lava Flow no es removido, puede continuar proliferando como código al ser usado en otras áreas.
• Si el proceso que conlleva al Lava Flow no es verificado, puede haber un crecimiento exponencial a medida que cada desarrollador, demasiado apurado o intimidado para analizar el flujo original, continúe produciendo nuevos o secundarios flujos a medida que tratan de evitar los originales, empeora la situación.
• A medida que el flujo se endurece, se hace rápidamente imposible de documentar el código o entender su arquitectura lo suficiente como para hacer mejoras.

Causas típicas

• Código proveniente de la investigación es colocado en producción sin pensar en la gestión de la arquitectura.
• Distribución sin controlar de código  sin terminar. La aplicación de muchos enfoques para implementar alguna funcionalidad.
• Un solo desarrollador (lone wolf) escribiendo el código.
• Falta de gestión de arquitectura y conformidad con la política de gestión de procesos.
• Falta de arquitectura o un desarrollo sin orientación a una arquitectura. Esto es especialmente frecuente en equipos de desarrollo altamente transitorios.
• Procesos repetitivos de desarrollo. A menudo, los objetivos del proyecto de software no son claros o cambian repetidamente. Para hacer frente a los cambios el proyecto debe reelaborar, dar marcha atrás y desarrollar prototipos. En respuesta a los plazos de demostración, hay una tendencia a hacer cambios precipitados al código "sobre la marcha" para hacerle frente a los problemas inmediatos. El código nunca es limpiado, dejando la evaluación de la arquitectura y la documentación, aplazadas indefinidamente.
• Cicatrices en la arquitectura. A veces, se compromete la arquitectura durante la etapa de análisis de los requerimientos y no se detecta sino hasta después de haber hecho cierta cantidad de desarrollo. Y aunque la arquitectura del sistema puede ser reconfigurada, estos errores en línea son raramente removidos. Puede incluso no ser factible comentar el código innecesario, especialmente en entornos modernos de desarrollo en donde cientos de archivos individuales comprenden la arquitectura del sistema. "¿Quién va a buscar en todos esos archivos? Simplemente hay que compilarlos!".

Excepciones conocidas

En menor escala, los prototipos del tipo "usar y tirar" en un entorno de investigación son idealmente adecuados para implementar el antipatrón Lava Flow. Es esencial para entregar rápidamente y el resultado no es requerido para ser  sostenible.

Solución refactorizada

Hay sólo una forma segura de prevenir este antipatrón: Asegurarse que las buenas prácticas de arquitectura precedan al desarrollo de código de producción. Esta arquitectura debe ser resguardada por un proceso de gestión que asegure la conformidad arquitectónica y se adapte "la misión" (requisitos cambiantes).

Si la consideración de la arquitectura es omitida, al final, el código que se desarrolla no es parte de la arquitectura a la que se apunta y por lo tanto, es redundante o muerto. Con el tiempo, este código muerto se convierte en un problema para el análisis, testing y revisión.

En los casos en que Lava Flow ya existe, la cura puede ser dolorosa. Un principio importante es evitar los cambios de arquitectura durante el desarrollo activo. En particular, esto aplica a las interfaces de software que definen la solución de integración de sistemas. La gestión debe posponer el desarrollo hasta que una arquitectura clara haya sido definida y distribuida a los desarrolladores.

Definir la arquitectura puede necesitar uno o más sistemas de detección de actividades. Un sistema de detección es necesario para localizar los componentes que son realmente usados y necesarios para el sistema. Además, define aquellas líneas de código que pueden ser eliminadas sin problemas. Esta actividad es tediosa; puede requerir las habilidades investigativas de un experimentado detective de software.

Cómo el código sospechoso de ser Dead Code es eliminado, se introducen bugs. Cuando esto sucede, se debe resistir la urgencia de arreglar el síntoma sin comprender totalmente la causa del error. Estudiar las dependencias. Esto ayudará a definir mejor la arquitectura a la que se apunta.

Para evitar el Lava Flow, es importante establecer un nivel de interfaces del software que sea estable, bien definido y claramente documentado. La inversión por adelantado en las interfaces de software de calidad puede producir grandes beneficios a largo plazo comparado con el costo de "taladrar" glóbulos endurecidos de lava.

Herramientas tales como las de control de código fuente (SCCS), asisten en la gestión de la arquitectura. SCCS está incluido con la mayoría de los entornos Unix y proporcionan una capacidad básica de guardar las historias de actualizaciones a los archivos del proyecto controlado.

Soluciones relacionadas

En el mundo competitivo de hoy, a menudo es deseable minimizar el tiempo que se demora entre la investigación y la producción. En muchas industrias, esto es crítico para la supervivencia de una compañía. Donde este es el caso, la inoculación contra Lava Flow puede, a veces, ser encontrada en un proceso de gestión de configuración (CM) personalizado que pone cierto controles de límitación en su lugar en la etapa de creación de prototipos, similar a "hooks" en un verdadero desarrollo de clase de producción sin el impacto de restricción completo en la naturaleza experimental de la investigación.

En donde sea posible, la automatización puede jugar un gran rol, pero la clave yace en la personalización de un cuasi proceso de CM que puede puede ser fácilmente escalado hacia un sistema de control completo de CM una vez que el producto se mueve hacia el entorno de producción. La cuestión es el equilibrio entre el costo de CM en obstaculizar el proceso creativo y el costo de obtener el control rápidamente del desarrollo una vez que el proceso creativo ha dado a luz algo útil y vendible.

Aplicabilidad a otros puntos de vista y escalas

El punto de vista arquitectónico juega un rol clave en la prevención de Lava Flow inicialmente. Los administradores pueden también jugar un rol importante al identificar tempranamente Lava Flows o las circunstancias que pueden conducir hacia este antipatrón. Estos administradores deben también tener la autoridad de poner los frenos cuando un Lava Flow es identificado por primera vez. Posponiendo además el desarrollo hasta que una arquitectura clara haya sido definida y distribuida.

Como con muchos antipatrones, la prevención es siempre más barata que la corrección, entonces, una inversión inicial en una buena arquitectura y capacitación del equipo pueden por lo general asegurar a un proyecto contra este y muchos otros antipatrones. Si bien este costo inicial no muestra resultados inmediatos, sin dudas es una buena inversión.

Por Juan Barrionuevo