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