jueves, 12 de junio de 2008

Antipatrones de diseño.

Me encantó este resumen antipatrones de diseño (en inglés). Lo traduje yo mismo con alma de programador, así que sean suaves con las correcciones. Me puse creativo en un par de párrafos, no pude evitarlo. Creo que va a dar para desglosar en un par de posts.

  1. Patrones de Cremación (Cremational Patterns)
    1. Pobreza vil (Abject Poverty): Código tan difícil de mantener y testear que el hacerlo resulta en la succión absoluta del presupuesto del proyecto, dejándolo en la extrema pobreza.
    2. Cegador (Blinder): Código que resuelve rápidamente el problema sin preocuparse por futuros cambios en los requerimientos. No está claro si el término se refiere a la cegera de aquellos que lo escribieron o a su deseo de sacarse los ojos durante la fase de mantenimiento.
    3. Falacia (Fallacy Method): Se presenta en el manejo de casos límite. El código parece correcto, pero si alguien se preocupara en probarlo, o si un caso límite apareciera, las fallas en su lógica se harían evidentes.
    4. Proto-Prueba (ProtoTry): Es un desprolijo intento de desarrollar rápidamente un modelo operativo del sistema. La intención original era reescribirlo utilizando la experiencia acumulada, pero las restricciones de tiempo en la planificación del proyecto nunca lo permitieron. También es conocido como "código heredado" (legacy code).
    5. Simpleza (Simpleton): Código extremadamente complejo para llevar a cabo la más simple y rutinaria de las tareas. Es una medida precisa de la habilidad de su creador.
  2. Patrones desestructurados (Destructural Patterns)
    1. Adoptivo (Adopter): Provee un hogar para funciones huérfanas que nadie sabe dónde ubicar. El resultado es una gran familia de funciones que no se parecen en nada y cuya única relación está dada por el hecho de pertenecer a la misma clase o módulo.
    2. Brig (¿traducción?): Es un contenedor para software pobremente desarrollado. También es conocido como módulo.
    3. Compromiso (Compromise): Balancea las siempre enfrentadas fuerzas de la planificación y las de la calidad, dando como resultado software de pobre calidad entregado fuera de tiempo.
    4. Detonador (Detonator): Es un patrón extremadamente común y usualmente no detectado. Un ejemplo son los cálculos basados en los dos últimos dígitos del año. ¡La bomba esta ahí fuera y esperando para explotar!
    5. Queso suizo (Fromage): Código lleno de agujeros. Software inconsistente lleno de pequeños trucos dependientes de la plataforma que hacen que sea imposible de actualizar. Cuanto más viejo se vuelve, más podrido huele.
    6. Diseño volador (Flypaper): Especificación creada por un diseñador y mantenida por otro, quien se encuentra absolutamente enredado en el trabajo del primero y usualmente muere antes de volverse loco.
    7. Pegamento de contacto (ePoxy): Código en módulos firmemente acoplados. A medida que el acoplamiento crece, parece haber una capa de pegamento de contacto entre ellos.
  3. Patrones de mala conducta (Misbehavioral Patterns)
    1. Cadena de posibilidades (Chain of Possibilities): Grandes módulos o clases pobremente documentadas. Nadie está seguro de hasta dónde se extiende su funcionalidad, pero las posibilidades parecen infinitas. También conocido como "no determinista".
    2. Comando (Commando): Código diseñado para llegar hasta su objetivo y hacer el trabajo entrando y saliendo rápidamente. Puede romper cualquier encapsulamiento para cumplir con su misión. No toma prisioneros.
    3. Intersperser (¿traducción?): Funcionalidad desparramada en varias porciones de código a través del sistema, haciéndola imposible de probar, modificar o comprender.
    4. Instigador (Instigator): Código aparentemente benigno pero que provoca fallos en partes insospechadas del sistema.
    5. Supernova (Momentum): Código que crece exponencialmente en tamaño, requerimientos de memoria, complejidad y tiempo de proceso en un corto período de tiempo.
    6. Sedante (Medicator): Código que consume tiempo de proceso haciendo que el resto del sistema parezca estar fuertemente sedado.
    7. Absolvedor (Absolver): Código mayormente desarrollado por ex-empleados, al que acuden los programadores actuales para lavar su culpas ante cualquier problema reportado. También es conocido como "no está en mi código".
    8. Orgullo (Stake): Código escrito por empleados que luego han elegido (correctamente) el camino del gerenciamiento de proyectos. Si bien está lleno de problemas, el ex-desarrollador, ahora líder de proyecto, está tan comprometido con él que no deja que nadie lo reescriba o siquiera ponga en duda, dado que representa su mayor logro técnico.
    9. Panegírico (Eulogy): Eventualmente aparece en proyectos que han utilizado los patrones anteriores y que una vez terminados son recordados amablemente. También es conocido como Post Mortem.
    10. Tempestad (Tempest Method): Código desarrollado en los días previos a la entrega del software. Está caracterizado por falta de comentarios e introducción de varios detonadores.
    11. Visitante del infierno -o Visita inesperada- (Visitor From Hell): Ciclo que no reconoce límites. Inevitablemente, al menos un ciclo del sistema tendrá un visitante del infierno que sobrescribirá datos críticos.

4 comentarios:

Anónimo dijo...

la verdad que este tema esta muy poco desarrollado, y existen muchisismos antipatrones de distintos tipos, (desarrollo, arquitectura, administracion)y no son tenidos en cuenta, el titulo resulta engañoso,ya que, da la sensacion de que se va a hablar de un tema general, y se centra en un tipo particuar.

AcP dijo...

Qué escaso sentido del humor.

Anónimo dijo...

Opino igual que el anonimo de arriba, el tema es mucho mas extenso que esto, deberias desarrollarlo un poco mas, o poner algunos ejemplos como para que sea un resumen aceptable. Tomalo como una critica constructiva, ahora si no te gustan las criticas entonces directamente no publiques en internet. No se cual fue el sentido de tu respuesta, cualquiera de los que caemos desde Google en tu post no venimos precisamente a buscar "Humor".

lafatiga dijo...

El problema del post es el titulo, ya que lo que expone no son antipatrones sino una sátira (bastante graciosa por cierto) de los patrones de diseño GOF. Basta con ver los nombres de estos "antipatrones" o el titulo del paper original: Resign Patterns Ailments of Unsuitable Project-Disoriented Software (VS Design Patterns Elements of Reusable Object-Oriented software.).