Your SlideShare is downloading. ×
0
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
200610 - Antipatrones de Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

200610 - Antipatrones de Software

5,193

Published on

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,193
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
33
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. cómo NO hacer programas Las mejores prácticas MCs Javier González Sánchez
  • 2. Introducción: has escuchado algo como esto: www.javiergs.com javiergs@acm.org
  • 3. Introducción: o como esto: www.javiergs.com javiergs@acm.org
  • 4. Introducción: entonces el siguiente manual es para tí Técnicas para hacer un PESIMO sistema de software Técnicas para hacer un PESIMO sistema de software 1. 1. Programación estilo volcán Programación estilo volcán 2. 2. El programa Dios El programa Dios 3. 3. La barita mágica La barita mágica 4. 4. Reinventar la rueda Reinventar la rueda 5. 5. Casarse con el diablo Casarse con el diablo 6. 6. El equipo superpoderoso El equipo superpoderoso 7. 7. Código spaghetti Código spaghetti 8. 8. Fantasmas Fantasmas 9. 9. Estufa y chimenea Estufa y chimenea 10. Y mucho más … 10. Y mucho más … www.javiergs.com javiergs@acm.org
  • 5. Técnica 1: Lava Flow programar al estilo volcán Síntomas: Declaración de Variables no justificadas. Clases grandes y complejas sin documentar que no se relacionan claramente con la arquitectura Inconsistente y difuso estilo de evolución de una arquitectura Bloques completos de código comentado sin explicación o documentación Muchas áreas con código por terminar o reemplazar Código sin uso abandonado, interfaces o componentes obsoletos en el cuerpo Consecuencias: Definición: Si el código de flujo de lava no es removido del código puedo seguir proliferando cuando el código es reusado en construir grandes cantidades de código de otras áreas. manera desordenada, con poca Si el proceso que sufre de flujo de lava no es revisado, documentación y poca claridad de su función puede haber un crecimiento geométrico de estos flujos, ya en el sistema. Conforme el sistema avanza en que muchas veces los programadores que continúan su desarrollo y crece, se dice que estos flujos trabajando con la versión original trabajan alrededor del flujo de lava se solidifican, es decir, se vuelve original mucho más complicado corregir los problemas Conforme los flujos se endurecen y solidifican, rápidamente se originados por estos, y el desorden va vuelve imposible documentar el código o entender su creciendo geométricamente. arquitectura lo suficientemente bien como para hacer mejoras www.javiergs.com javiergs@acm.org
  • 6. Técnica 2: The God un programa omnipresente y desconocido Síntomas: Una sola clase en la implementación de todo el sistema Consecuencias: Dependencia total de esa clase Código desorganizado Fuerte interdependencia Definición: Una sola clase ó modulo hace todo Tu programa es un SOLO archivo de muuuuuchas líneas www.javiergs.com javiergs@acm.org
  • 7. Técnica 3: Golden Hammer también conocida como la técnica de la barita mágica Síntomas: Uso obsesivo de herramientas Terquedad de los desarrolladores para usar un paradigma de solución para todos los programas Mala elección Consecuencias: Consumir mucho más esfuerzo para resolver un problema Definición: Es un vicio referente a aferrarse a un paradigma para solucionar todos los problemas que se nos presenten al desarrollar sistemas, como por ejemplo siempre querer usar el mismo lenguaje de programación para todos los desarrollos sea o no conveniente. www.javiergs.com javiergs@acm.org
  • 8. Técnica 4: reinventar la rueda eso reinventar la rueda Síntomas: Poco nivel de reuso en el código Constantemente se reescriben fragmentos de código Hay pocos métodos procedimientos o funciones Consecuencias: El software se vuelve innecesariamente más denso Definición: Se pierde tiempo e reimplementar cosas que ya estaban hechas Se refiere a reimplementar componentes prefabricados de antemano y hacer poco Se puede perder consistencia reuso en el código. Querer hacer todo uno mismo www.javiergs.com javiergs@acm.org
  • 9. Técnica 5: Vendor lock-in o casarse con el diablo Síntomas: Poco conocimiento del trabajo ya existente Se buscan soluciones a problemas ya solucionados Consecuencias: Se depende completamente de lo que el vendedor haga La calidad de los productos del proveedor nos Definición: comprometen Crear una dependencia hacia un fabricante El vendedor nos tiene agarrados que nos provee de alguna solución (componentes). www.javiergs.com javiergs@acm.org
  • 10. Técnica 6: Mythical Month Man el súper equipo de programadores Síntomas: Se trata de corregir retraso asignando más personal No importa cuanto personal se aumente, el proyecto sigue sin avanzar Consecuencias: Llega un punto que entre más personal se asigne más se retrasa el proyecto Definición: Consiste en la creencia de que asignar más personal a un proyecto acotará el tiempo de entrega. www.javiergs.com javiergs@acm.org
  • 11. Técnica 7: Spaghetti Code o programar con las … los “pies” Síntomas: 50% del tiempo de mantenimiento se invierte en entender al sistema original. El programa creado para hacer un pequeño demo, en un dos por tres esta trabajando como producto final. El trabajo fue hecho pro el “Programador Solitario” ¿Quién era ese hombre enmascarado? Síndrome del programador desesperado: ¡mejor reescribimos todo el programa! Definición: El reuso es imposible Spaghetti: dicese de una pieza de código fuente no documentado, dónde cualquier pequeño movimiento convulsiona la estructura completa del sistema. Consecuencias: Nota: Tienes problemas, muchos problemas, disfrútalos. Si mezclamos más de un lenguaje de programación en el mismo archivo el Spaghetti es más sabroso. Ej. PHP con HTML sazonado con JavaScript, es delicioso! www.javiergs.com javiergs@acm.org
  • 12. Técnica 8: Poltergeist fantasmas Síntomas: El modelo de análisis y/o diseño es inestable El diseño no coincide con la implementación El rendimiento del sistema es pobre Imposible hacer extensiones al sistema, entre tanto “fantasma” encontrar los elementos relevantes se imposibilita. Consecuencias: Definición: Demasiadas clases en un programa o tablas Sigues teniendo problemas, pero no te asustes solo échale la en una base de datos. Muchas clases o tablas culpa al programador que estaba antes en tu lugar. con mínimas responsabilidades. www.javiergs.com javiergs@acm.org
  • 13. Técnica 9: Stovepipe cocinado en “caliente” Síntomas: Falta de estrategia tecnológica de la empresa. Falta de estándares. Falta de perfil de sistema. Falta de incentivos para la cooperación en el desarrollo de sistemas. Falta de comunicación Falta de conocimiento sobre los estándares tecnológicos. Falta de interafaces para la integración de sistemas Consecuencias: Definición: Tecnologías incompatibles dentro de la misma empresa En la empresa se desarrollan varios sistemas Arquitecturas monolíticas y no documentadas de manera independiente y a distintos niveles. Falta de posibilidad de extender los sistemas para Esto dificulta interoperabilidad, reuso e satisfacer las necesidades de negocio incrementa costos. Se crean islas automatizadas dentro de la misma empresa. Falta de estándares Falta de reuso Falta de interoperabilidad www.javiergs.com javiergs@acm.org
  • 14. Más técnicas: alguna es de tu agrado o quizás prefieras alguna de estas: La técnica POCP [Programación orientada a Cut & paste] La técnica CTE [Cubre Tus Errores] La técnica de morir planeando La técnica de la navaja suiza La técnica del viejo y poderoso Duke de York La técnica de la esponja La técnica de la Cosa www.javiergs.com javiergs@acm.org
  • 15. ¿Administras proyectos de desarrollo de software? entonces este anexo es para tí 1. 1. El DES-administrador El DES-administrador 2. 2. La mazorca de empleados La mazorca de empleados 3. 3. Y otros más … Y otros más … www.javiergs.com javiergs@acm.org
  • 16. Estrategia 1: Project Miss-management la jefa o el jefe que no sabe mandar Síntomas: Retrasos en las fechas de entrega. Áreas incompletas. Consecuencias: No se cumplen con las fechas de entrega Definición: EL proyecto se descuida y no se monitorea de manera adecuada, es muy difícil de detectar en etapas iniciales pero repentinamente emerge de golpe y suele voltear de cabeza negativamente la situación del proyecto. www.javiergs.com javiergs@acm.org
  • 17. Estrategia 2: Corncob los empleados se obstaculizan unos a otros Síntomas: El proyecto no se desarrolla correctamente aunque el personal es bueno Consecuencias: El proyecto puede fallar por causas completamente ajenas a él. Definición: Personas conflictivas o difíciles de tratar que forman parte del equipo de desarrollo desvían u obstaculizan el proceso de producción porque transfieren sus problemas personales o diferencias con otros miembros del equipo al proyecto. www.javiergs.com javiergs@acm.org
  • 18. Más estrategias: puedes considerar también: El supervisor paranoico Miedo al éxito La pelea www.javiergs.com javiergs@acm.org
  • 19. Conclusiones: Todos estos problemas tienen una receta que los soluciona SOFTWARE ARCHITECTURE GOOD PROJECT MANAGEMENT www.javiergs.com javiergs@acm.org

×