Antipatrones de desarrollo de software: Spaghetti Code

Se trata del antipatrón más famoso. Es un clásico. Ha existido, de una forma u otra, desde la invención de los lenguajes de programación. Los lenguajes que no son orientados a objetos, parecen ser más susceptibles a este antipatrón, pero es bastante común entre los desarrolladores que aun tienen que dominar plenamente los conceptos avanzados que subyacen la programación orientada a objetos.

Generalidades

El Spaghetti Code aparece como un programa o sistema que contiene muchas estructuras pequeñas de software. La codificación y extensión progresiva comprometen la estructura del software de tal manera que pierde claridad, incluso para el programador original, si él o ella se encuentran lejos de ese código por un tiempo prolongado.

Si se ha desarrollado utilizando un lenguaje orientado a objetos, el software puede incluir un pequeño número de objetos que contienen métodos con implementaciones realmente grandes.

Además, los métodos de los objetos son invocados de una manera muy predecible y hay un grado insignificante de interacción entre los objetos en el sistema. El sistema es muy difícil de mantener y extender. No hay oportunidad de reutilizar los objetos y módulos en sistemas similares.

Síntomas y consecuencias

• Después de extraer código, sólo partes de los objetos y métodos parecen ser reutilizables. Dividir código spaghetti a menudo puede ser tomada como una mala inversión por parte de la empresa (aunque reporta un beneficio posterior). Por este motivo, debe tenerse muy en cuenta antes de tomar la desición de la división.
• Los métodos están muy orientados a procesos; frecuentemente, de hecho, los objetos tienden a tener nombres de procesos.
• El flujo de ejecución es determinado por la implementación del objeto y no por los clientes del objeto.
• Existe una mínima relación entre objetos.
• Muchos métodos de objetos no tienen parámetros y utilizan variables de clase o globales para procesar.
• El código es difícil de reutilizar, y cuando lo es, a menudo es porque se lo ha clonado (Copy - Paste). De cualquier manera, en muchos casos, el código nunca es considerado para reutilizarlo.
• Se pierden los beneficios de la orientación a objetos.
• El software alcanza rápidamente un punto de rendimiento decreciente; el esfuerzo que involucra el mantenimiento del código existente es mayor que el costo de desarrollar una nueva solución desde cero.

Causas típicas

• Inexperiencia con las tecnologías de diseño orientadas a objetos.
• Inexistencia de tutoría.
• Revisión de código ineficiente.
• No se diseña antes de implementar.

Solución

El refactoring de software o code cleanup es una parte esencial del desarrollo. Pero al menos un 70 porciento, o más, del tiempo debe ser dedicado a la extensión del sistema; por ello es crítico mantener una estructura coherente que soporte dicha extensión.
Cuando la estructura se ve comprometida por tener que soportar necesidades imprevistas, la habilidad del código para soportar extensiones se vuelve limitada y eventualmente, inexistente. El término code cleanup no apunta a los administradores, entonces resulta mejor usar el término software investment.
Después de todo, el refactoring es el mantenimiento de la inversión hecha en el software. Un código bien estructurado tendrá un ciclo de vida mucho más largo y una mejor habilidad para soportar cambios.
La mejor manera de resolver este antipatrón es la prevención. Esto es, pensar luego desarrollar un plan de acción para finalmente escribir el código. Ahora, si el código ya está degenerado a un punto tal de estar "inmantenible" y la reingeniería no es una opción, hay que tener en cuenta no profundizar el problema.

• No modifique el código simplemente para agregar la nueva funcionalidad. En lugar de esto, pierda un poco de tiempo realizando un refactoring del código existente haciéndolo un poco más mantenible.
• Insistir en un apropiado proceso de análisis orientado a objetos para crear modelos de dominio.

Por Juan Barrionuevo