Un patrón software es una solución común, adaptable y probada para un problema conocido. Algo así como una plantilla de encaje que se ajusta a según qué condiciones (fuerzas y contexto) de manera que aporta una solución (diseño) implementable y ejecutable (software).
Un antipatrón es precisamente lo contrario. Dicho así de pronto parece claro que es algo así como un “lo que no hay que hacer” y que por tanto lo que voy a tratar aquí es un compendio de malas prácticas. Pero un antipatrón no es exactamente esto. Existen muchos libros que tratan de buenas y malas prácticas: en análisis, en diseño, en implementación, en pruebas… Un antipatrón no es una mala práctica, aunque su consecuencia es un mal diseño y por tanto puede abocar al fracaso de un producto software.
Un antipatrón es la aplicación de un patrón software bajo unas precondiciones erróneas, es decir: la aplicación de un patrón software en un contexto equivocado. Es algo así como decir: “tu intención era buena peeero no estudiaste bien las fuerzas y el contexto que intervenían en tu situación particular, y por ello tu solución es inadecuada”.
Bueno, esto parece diferente a lo que tradicionalmente considerábamos como mala praxis en el desarrollo software, y parece tener algo de atractivo. En estos momentos estoy leyendo un librito que trata este tema, y a medida que encuentre temas interesantes que pueda publicar lo haré. Veamos si no es un palabro más inventado para escribir libros y ganar dinero.
Lo que expongo a continuación es un breve resumen de patrones y antipatrones extraídos de la fuente que anexo al final del artículo. Para ir abriendo boca.
Antipatrones:
Artefacto no reutilizable: No sólo es aquel que no es reutilizable porque no se pensó en ello, sino que también es aquél que se pretendió que fuera reutilizable pero que en realidad no lo es (y esto último es más importante y más grave).
Reutilización orientada a repositorios: La creencia de que simplemente por crear una especie de almacén de piezas software que se pueden reutilizar, la reutilización viene de forma automática.
Síndrome del No-Está-Hecho-Aquí: Los desarrolladores desconfían del trabajo hecho por otros y tienden a desarrollar por sí mismos artefactos software que ya están hechos.
Reusabilidad declarada: La creencia de que algo es reutilizable simplemente porque lo digo yo o lo dijo alguien…
Reusabilidad orientada a incentivos: Una vez más, ofrecer incentivos para que los desarrolladores hagan software de mayor calidad (en este caso, reutilizable) no es el camino, pequeño saltamontes…
Producción antes de consumición: Algo así como que la reutilización vendrá por sí sola en cuanto empieces a pensar en desarrollar artefactos reutilizables. La realidad es que es necesario invertir fuertemente para que la reutilización sea un hecho probado: dedicar recursos y soporte.
Reutilización solamente de código: Creer que lo único susceptible de ser reutilizado es el código.
Reutilización orientada a proyectos: Limitar la generalización que lleva a construir artefactos reutilizables solamente como decisión que incumbe al ámbito del proyecto para el cual se desarrolla dicho artefacto.
No hay comentarios:
Publicar un comentario