200610 - Antipatrones de Software

cómo NO hacer programas Las mejores prácticas MCs Javier González Sánchez

Introducción: has escuchado algo como esto: www.javiergs.com javiergs@acm.org

Introducción: o como esto: www.javiergs.com javiergs@acm.org

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

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

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

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

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

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

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

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

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

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

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

¿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

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

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

Más estrategias: puedes considerar también: El supervisor paranoico Miedo al éxito La pelea www.javiergs.com javiergs@acm.org

Conclusiones: Todos estos problemas tienen una receta que los soluciona SOFTWARE ARCHITECTURE GOOD PROJECT MANAGEMENT www.javiergs.com javiergs@acm.org

http://sed.ucla.edu.ve	568
http://programacionbizarra.blogspot.com	54
http://www.slideshare.net	29
http://static.slidesharecdn.com	2
http://javiergs.com	1
http://programacionbizarra.blogspot.com.es	1
http://programacionbizarra.blogspot.com.ar	1

200610 - Antipatrones de Software

by Javier Gonzalez Sanchez on Jul 06, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 656

Statistics

200610 - Antipatrones de Software — Presentation Transcript