1. Anti-patrones
Rocío Amaya (rochi)

2. Anti-patrones
Según James Coplien, un anti-patrón es...
“...algo que se ve como una buena
idea, pero que falla malamente cuando
se la implementa.”

3. ¿Qué son?
Son una falla de diseño de aplicaciones.
Son mala soluciones a problemas.
Un buen anti-patrón explica:
por qué la solución original parece
atractiva.
por qué se vuelve negativa.
y cómo recuperarse de los problemas que
ésta genera.

4. ¿Por qué estudiarlos?
La idea que sobre la creencia de que es más fácil
detectar lo que se hace mal que proveer un
buen comportamiento.
Son un método eficiente para vincular una
situación general a una clase de solución
específica.
Proveen experiencia del mundo real para
reconocer problemas recurrentes en la industria
del software, ofreciendo también una solución
para sus implicaciones más comunes.

5. ¿Por qué estudiarlos?
Establecen un vocabulario común para identificar
problemas y discutir soluciones.
Soportan la resolución de conflictos, utilizando
recursos organizacionales a diferentes niveles.
Su conocimiento sirve para:
Intentar evitarlos.
Recuperarse de ellos.

6. Tipos de anti-patrones
Codificación o desarrollo:
Se centran en problemas asociados al
desarrollo de software a nivel de aplicación.
Arquitectura:
Se centran en la estructura de las
aplicaciones y componentes a nivel de
sistema y empresa.
Administración de proyectos:
Problemas de comunicación entre personas.

7. Codificación o desarrollo
The Blob
Lava Flow
Functional Decomposition
Poltergeists
Golden Hammer
Spaghetti Code
Cut and Paste Programming
Mini antipatterns:
Continuous Obsolescence
Ambiguous Viewpoint
Walking through a Minefield
Dead End
Input Kludge
Boat Anchor

8. The Blob (o God Class)
Definición:
Una sola clase que hace todo.
Síntomas:
Una clase grande, muchos métodos no
relacionados y sin argumentos.
Consecuencias:
Pérdida de las ventajas de la OO.
Dependencia total a esa clase.
Difícil rehúso o testeo.

9. The Blob (o God Class)
Solución:
Separar en pequeñas clases.
Evitar asociaciones transitivas.
Minimizar la complejidad del Blob quitando
responsabilidades y repartiéndolas en otras
clases en forma sensata.

10. Lava Flow (volcán)
Definición:
Grandes cantidades de código y con poca
claridad de su función. Se vuelve complicado
corregir los problemas ya que el desorden va
creciendo geométricamente
Síntomas:
Código que nadie entiende.
Código “abandonado”, comentado.
Diseño no documentado.
Código que no puede ser testeado
Bloques de código comentado sin explicación

11. Lava Flow (volcán)
Consecuencias:
Baja performance en el sistema.
Dificultad para extenderlo o depurarlo.
En caso de ser rehusado el problema se traslada
Solución:
Aplicar técnicas de revisión.
Eliminar código muerto.
Refactorizar.

12. Poltergeists
Definición:
Emplear objetos cuyo único propósito es pasar la
información a terceros objetos.
Síntomas:
Gran numero de clases pequeñas poco
descriptivas, con usos limitados o
responsabilidades muy puntuales
Consecuencias:
Baja performance del sistema
Solución:
Eliminarlos y poner su funcionalidad en la clase
a la que invocan.

13. Golden Hammer
(o varita mágica)
Definición:
Se refiere al uso de una tecnología, patrón,
arquitectura etc.. para cualquier problema o
situación incluso cuando es evidente que no va
ser útil.
Síntomas:
Las soluciones encontradas son inferiores en
calidad a otras existentes.
Consecuencias:
Dependencia
Solución:
Expandir conocimientos

14. Spaghetti Code
Definición:
Código en el cual el flujo de control es muy
variado y complicado. En OO, los objetos son
básicamente funciones con poca interacción
entre ellos.
Síntomas:
Un cuerpo de código realizando más de una
función.
Es más fácil reescribir todo que modificar algo.
Falta documentación.

15. Spaghetti Code
Consecuencias:
Cerca del 50% del tiempo de las operaciones de
mantenimiento de este tipo de aplicaciones se
invierte en descubrir como funcionan
Solución:
Hacer código limpio.
Refactorizar.
Crear funciones de alto nivel.
Crear una buena jerarquía de objetos.

16. Cut and Paste
Definición:
Programar copiando y modificando código
existente en lugar de crear soluciones genéricas.
Síntomas:
El mismo error vuelve a aparecer a lo largo del
software a pesar de los muchos arreglos locales

17. Cut and Paste
Consecuencias:
Conduce a costos excesivos de mantenimiento
de software.
Se hace difícil de localizar y corregir todos los
casos de un error en particular.
Solución:
Refactorizar el código base.

18. Arquitectura
Vendor lock-in
Stovepipe enterprise
Architecture by implication
Design by committee
Reinvent the wheel
Mini antipatterns:
Autogenerated Stovepipe
Cover your Assets
The Grand Old Duke of York
Swiss Army Knife
Wolf Ticket
Jumble
Warm Bodies

19. Stovepipe Enterprise
Definición:
Empresa de copa o islas de automatización.
Síntomas:
Varios sistemas aislados entre sí, que no pueden
colaborar para crear sistemas mas grandes.
Tecnologías incompatibles dentro de la misma
empresa

20. Stovepipe Enterprise

21. Stovepipe Enterprise
Consecuencias:
Incompatible terminología, enfoques, y la
tecnología entre los sistemas de la empresa.
Falta de estándares, de rehúso y de
interoperabilidad
Solución:
Se define la infraestructura común y
convenciones comunes para los sistemas.

22. Stovepipe Enterprise

23. Vendor Lock-in
Definición:
Un proyecto adopta un producto de tecnología
sobre el cual se vuelve excesivamente
dependiente.
Síntomas:
El ciclo de mantenimiento está influenciado por los
cambios comerciales de la tecnología de base.
El producto final se diferencia bastante de los
estándares abiertos tradicionales.

24. Vendor Lock-in
Consecuencias:
Dependencia a cierto producto tecnológico
Solución:
Isolation layer.
Separar los paquetes de software y el
producto de tecnología, brindando
portabilidad e independencia

25. Architecture by Implication
Definición:
Falta de la especificación de la arquitectura. Los
desarrolladores consideran que la
documentación no es necesaria. Esta confianza
exagerada conlleva a riesgos que pueden
afectar el éxito del sistema.
Síntomas:
El desconocimiento de las nuevas tecnologías.
La ausencia de apoyo técnico y planes de
contingencia.

26. Architecture by Implication
Consecuencias:
Riesgos ocultos causados por la escala, el
conocimiento del dominio, la tecnología y la
complejidad, que surgen mientras avanza el
proyecto.
Fracaso de los proyectos inminentes o sistema de
éxito debido a un rendimiento insuficiente, el exceso
de complejidad, necesidades incomprendidas,
facilidad de uso, y las características del sistema.
Solución:
Documentación

27. Design by Committee
Definición:
"Demasiados cocineros estropean el caldo”,
llamado también Haz Feliz a Todo Mundo,
Partido Político, etc.
Síntomas:
La documentación del diseño es demasiado
compleja , defectuosa o voluminosa.
No existe la priorización en las estructuras
del diseño

28. Design by Committee
Consecuencias:
Las reuniones del comité se convierten en
sesiones poco productivas.
Pocas decisiones se pueden tomar fuera
del comité lo que atrasa mucho el
avance del proyecto
Solución:
Reorganizar el proceso de reuniones
Mini anti patrón: Navaja suiza

29. Reinvent the Wheel
Definición:
También llamado Diseñando en el vacío,
Inventando el hilo negro.
Querer implementar una solución,
la cual ya fue diseñada previamente.
Sintomas:
Repetición de funcionalidad de otro software
comercial.
Arquitecturas inmaduras e inestables.
Arquitecturas cerradas, útiles acotadamente,
sin previsión de rehusabilidad.
Inadecuado soporte para la administración de
cambios e interoperabilidad.

30. Reinvent the Wheel
Consecuencias:
La mala gestión de los riesgos y los costos,
lo que lleva a programar mas y superar el
presupuesto.
Imposibilidad para entregar las prestaciones
que desea para el usuario final; gran esfuerzo
para replicar la funcionalidad de otros sistemas
sistemas existentes.
Solución:
Extraer información valiosa enterrada en los
diseños ya existentes para su uso
(architecture mining)

31. Administracion de proyectos
Analysis paralysis
Death by planning
Corncob
Irrational managament
Project missmanagament
Mini antipatterns:
Blowhard jamboree
Viewgraph Engineering
Fire Drill
Throw it over the wall
E-mail is dangerous
Smoke & mirrors
Intellectual Violence
Fear of success
The Feud

32. Analysis Paralysis
Definición:
Muy común en objetos. Se busca la perfección y
la completitud en la etapa de análisis, siendo que
apenas avanzan en el diseño.
Síntomas:
Diseño y problemas de aplicación son
continuamente vueltos a introducir en la
fase de análisis.
El análisis excede el tiempo estimado.

33. Analysis Paralysis
Solucion:
Métodos de modelado y desarrollo que
separan un proyecto en etapas
iterativas, esto es, se analiza una parte
del problema, se diseña, se codifica y se
prueba lo desarrollado para luego volver
a analizar otra parte completando la
iteración.

34. Otros anti-patrones
Death by Planning:
Ocurre cuando el proyecto se demora por
excesiva dedicación a la preparación de planes
para el desarrollo del proyecto.
Corncob:
Los empleados se obstaculizan unos a otros.
Bajo esta circunstancia, el proyecto no se
desarrolla correctamente aunque el personal es
bueno.

35. Otros anti-patrones
The Mythical Month Man:
Consiste en la creencia de que asignar más
personal a un proyecto, acotará el tiempo de
entrega. Generalmente como una forma
desesperada de intentar corregir retraso del
proyecto. Llega un punto donde entre más
personal se asigne, más se retrasa el proyecto
Project Missmanagement:
No se monitorea el proyecto adecuadamente.
Resultado: retraso en la entrega, módulos
incompletos.

36. Conclusiones
Los anti-patrones dejan la enseñanza
de cuál es la mejor forma de NO
hacer sistemas de software
Las mejores prácticas de una época
pueden ser los anti-patrones de la
siguiente