Anti-patrones, La mejor forma de hacer un psimo
sistema de software.
Los anti-patrones, tambin llamados trampas, son ejemplos bien
documentados de malas soluciones para problemas. Se estudian a fin
de poderlos evitar en el futuro, y en su caso, para que su presencia
pueda ser reconocida fcilmente al investigar sistemas disfuncionales
durante una auditoria.
El trmino anti-patrn se origina como una contra parte al trmino
patrn, acuado en arquitectura de software, para definir las buenas
prcticas de programacin, diseo o gestin de sistemas. De tal
manera podramos hablar de que un sistema bien hecho est lleno
de patrones, y debera carecer de anti-patrones; al menos ese sera
un sistema ideal.
Los anti-patrones en arquitectura de software, son similares a sus
anlogos sociales, soluciones negativas, acciones que presentan
mayores problemas que soluciones. Sin embargo, representan un
camino fcil y rpido. Pero continuando con la analoga, podramos
pensar que si necesitas dinero, tienes dos opciones: el patrn (buen
comportamiento) trabajar arduamente o el anti-patrn (rpido y con
consecuencias a largo plazo) robar un banco.
El mismo concepto se aplica fcilmente en ingeniera, y en otras
actividades donde est presente el esfuerzo humano. As, antipatrones como reinventar la rueda, la cosa, el programa todo lo hace,
casarse con una sola tecnologa, la tubera de la estufa, corn cob
(juntos pero no revueltos), etctera. Dejan la enseanza de cul es la
mejor forma de no hacer sistemas de cmputo.
En la elaboracin de un sistema, intervienen al menos, diversos
actores: arquitectos de software, administradores de proyecto y
desarrolladores. Para cada uno de ellos, existen anti-patrones que
describen comportamientos y soluciones incorrectas Los anti-patrones
(una vez conocidos) constituyen para cada uno de los actores
involucrados, descripciones de problemas recurrentes en la
construccin de software, les proporcionan un vocabulario comn
para identificar problemas y discutir posibles soluciones y les sugieren
pasos para la re-ingeniera, y re-organizacin estructural de un
sistema.
Anti-patrones de Codificacin
1. Lava Flow.- Algo as como programar al estilo volcn. Es
construir grandes cantidades de cdigo de manera desordenada, con
poca documentacin y poca claridad de su funcin en el sistema.
Conforme el sistema avanza en su desarrollo, y crece, se dice que
estos flujos de lava se solidifican, es decir, se vuelve mucho ms
complicado corregir los problemas que originan, y el desorden va
creciendo geomtricamente.
Esto se hace patente cuando: 1. Se declaran variables no justificadas.
2. Se construyen clases o bloques de cdigo muy grandes y
complejas sin documentar, o que no se relacionan claramente con la
arquitectura. 3. Usando un inconsistente y difuso estilo de evolucin
de una arquitectura. 4. Cuando en el sistema existen muchas reas
con cdigo por terminar o reemplazar. 5. Y claro, cuando dejamos
cdigo sin uso abandonado; interfaces o componentes obsoletos en el
cuerpo del sistema. Los resultados son predecibles: conforme los
flujos se endurecen y solidifican (se escribe cdigo y pasa el tiempo),
rpidamente se vuelve imposible documentar el cdigo o entender su
arquitectura lo suficientemente bien como para hacer mejoras.
2. The God.- Un programa omnipresente y desconocido. Aquel
sistema donde una sola clase modulo (la funcin main o
equivalente) hace todo. As que el programa es un solitario y nico
archivo de muchsimas lneas. En consecuencia, tenemos un cdigo
desorganizado y fuertemente interdependendiente.
3. Golden Hammer.- Tambin conocida como la tcnica de la
barita mgica. Es un vicio relacionado con 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 programacin para todos los desarrollos, sea o no
conveniente. Es el caso de enamorarnos de .Net, de Java, de PHP. Es
importante comprender que cada uno tiene capacidades y
limitaciones en aplicaciones particulares. En consecuencia se trata de,
uno, el uso obsesivo de una herramienta, y dos, una terquedad de los
desarrolladores para usar un paradigma de solucin en todos los
programas. Lo cual conlleva ocasionalmente a consumir mucho ms
esfuerzo para resolver un problema.
4. Spaghetti Code.- Se dice de una pieza de cdigo fuente no
documentado, donde cualquier pequeo movimiento convulsiona la
estructura completa del sistema. En expresin coloquial: codificar con
las... los pies. A diferencia del estilo volcn, donde la crtica es a la
forma en que el sistema crece (se anexan mdulos), aqu la crtica es
a la forma en que se escribe cada una de las lneas, desde la
indentacin hasta el lenguaje o lenguajes utilizados y su interaccin.
Ya en el contexto spaghetti, si mezclamos ms de un lenguaje de
programacin en el mismo archivo, el spaghetti es ms sabroso. La
receta clsica con lenguajes scripts del tipo PHP con HTML y sazonado
con JavaScript, es delicioso! (entindase un enorme problema). El
origen del spaghetti es regularmente un programa creado para hacer
una pequea demostracin, que termina, en un dos por tres,
trabajando como producto final.
Donde est el problema, bien podemos citar lo siguiente como
ejemplos: 1. 50% del tiempo de mantenimiento se invierte en
entender al sistema original. 2. El spaghetti es causa directa del
sndrome del programador desesperado: mejor reescribimos todo el
programa! 3. Y obviamente el reuso es imposible.
Pero si para colmo, tenemos slo un chef, o en el contexto un
Programador Solitario. Quin era ese hombre tras el monitor? Que
no est disponible para explicarnos su receta. Simplemente se tienen
problemas, muchos problemas.
5. Fantasmas.- Demasiadas clases en un programa o tablas en
una base de datos. Varias clases o tablas con mnimas
responsabilidades. Muchas veces se utiliza para disfrazar la presencia
del anti-patrn The God. Se colocan clases intiles, que disfrazan el
hecho que todo el sistema se encuentra construido en uno, o unos
cuantos archivos, mdulos o clases. Este anti-patrn sugiere un
modelo de anlisis y/o diseo inestable: el diseo no coincide con la
implementacin, y por ello es imposible hacer extensiones al sistema,
porque entre tanto fantasma, encontrar los elementos relevantes es
imposible.
Anti-patrones de Arquitectura
Ahora consideremos las malas tcnicas para definir componentes y
relaciones en el sistema, es decir, su arquitectura. Si los
desarrolladores tienen una coleccin de malas costumbres de
codificacin (anti-patrones) a su alcance, los arquitectos no nos
quedamos atrs. Veamos:
6.
Reinventar la rueda.- Se refiere a reimplementar
componentes que se pueden conseguir prefabricados de antemano, y
hacer poco reuso en el cdigo. En breves palabras: querer hacer todo
uno mismo. Y hablaramos de: 1. Poco nivel de reuso en el cdigo,
reuso de un proyecto a otro, con lo cual cada proyecto est
comenzando desde cero. 2. Constantemente se reescriben
fragmentos de cdigo con la misma funcionalidad. 3. Con el
consecuente gasto intil de mano de obra y tiempo en reimplementar
cosas, que ya estaban hechas.
innecesariamente ms denso.
4.
El
software
se
vuelve
Lo anterior, por lo regular, a causa de poco conocimiento del trabajo
ya existente por parte del arquitecto, lo que conlleva a buscar
soluciones para problemas ya solucionados.
7. Casarse con una sola tecnologa: Crear una dependencia
hacia un fabricante que nos provee de alguna solucin
(componentes). El problema es inminente: 1. Se depende
completamente de lo que el vendedor haga. 2. La calidad de los
productos del proveedor nos comprometen. 3. El vendedor nos tiene
agarrados. Cito como ejemplo, el caso de una de las universidades
ms importantes del pas, cuyo desarrollo casi completo del sistema
de administracin escolar, est realizado sobre PL/SQL en Oracle.
Ellos necesitan seguir pagando las licencias de Oracle para
mantenerse operando. An cuando los nuevos desarrollos los estn
elaborando ya en otras plataformas Java y PhP, entre otras. Tienen
cinco aos de desarrollos en PL/SQL, que no los dejan dejar de pagar
licencias. No es que Oracle sea malo. Sin embargo, puede ser caro en
extremo para una universidad pblica.
8. Stovepipe.- Cocinado en caliente. Es la forma breve de
referirse a la creacin de islas automatizadas dentro de la misma
empresa (cada departamento crea su propio subdepartamento de
sistemas). Islas independientes, y en conflicto unas con otras. Cada
isla desarrolla la parte del sistema que necesita para satisfacer sus
requerimientos, sin preocuparse por el resto (no existe un plan o eje
gua), el escenario resultante implica una pobre o nula
interoperabilidad,
obviamente,
no
existe
el
reuso
y,
consecuentemente se incrementan costos. Contrario a lo que se
podra suponer, cada vez es ms comn este tipo de acciones, dada
la premura de departamentos especficos dentro de una macroempresa, por contar con acceso a Tecnologas de Informacin.
Hablamos de un escenario donde prevalece: 1. Una falta de
estrategia tecnolgica de la empresa. 2. Falta de estndares. 3. Falta
de perfil de sistema. 4. Falta de incentivos para la cooperacin en el
desarrollo de sistemas. 5. Falta de comunicacin. 6. Falta de
conocimiento sobre los estndares tecnolgicos. 7. Falta de interfaces
para la integracin de sistemas.
Anti-patrones de Administracin de
Proyecto
Finalmente, los administradores tampoco estn exentos de seguir
ciertos anti-patrones:
9. The Mythical Month Man.- Mejor conocido como en el
entorno como el sper equipo de programadores. Consiste en la
creencia de que asignar ms personal a un proyecto, acotar el
tiempo de entrega. Regularmente como una forma desesperada de
intentar corregir retraso del proyecto. Llega un punto donde entre
ms personal se asigne, ms se retrasa el proyecto.
10. Project Miss-management.- La jefa o el jefe que no
saben coordinar. El proyecto se descuida y no se monitorea de
manera adecuada, es muy difcil de detectar en etapas iniciales, pero
repentinamente emerge de golpe y suele voltear de cabeza la
situacin del proyecto. Se manifiesta con retrasos en las fechas de
entrega y/o reas incompletas.
11. Corncob.- Los empleados se obstaculizan unos a otros.
Personas conflictivas o difciles de tratar que forman parte del equipo
de desarrollo, desvan u obstaculizan el proceso de produccin,
porque transfieren sus problemas personales o diferencias, con otros
miembros del equipo al proyecto. Bajo esta circunstancia, el proyecto
no se desarrolla correctamente aunque el personal es bueno.
Conclusin
El listado de anti-patrones es muy amplio, casi tanto como el de
patrones. Recomiendo a lector la consulta adicional de los siguientes:
La tcnica POCP (programacin orientada a cut & paste). La tcnica
CTE (cubre tus errores). La tcnica de morir planeando, la de la
navaja suiza; la tcnica del viejo y poderoso Duke de York, la tcnica
de la esponja, el supervisor paranoico, y la tcnica de la pelea.
Algunos de estos patrones, son incluso irrisorios, errores tan comunes
que se supondra nadie podra cometerlos, y sin embargo,
reflexionemos, cuntos de nosotros, estudiantes, profesionistas, es la
primera opcin a la que recurrimos. He deseado slo comentarlos, no
obstante, para cada uno de estos, existe un anlisis profundo y
minucioso de sus causas, sntomas, consecuencias y tratamiento.
Conocer los anti-patrones es til para refabricar, migrar, actualizar o
realizar reingeniera.
Con el avance tan vertiginoso de la tecnologa informtica, resulta
interesante comentar que las mejores prcticas de una poca,
pueden evolucionar y convertirse en anti-patrones en el lustro
siguiente. Hoy da, podemos citar, por ejemplo, la programacin
estructurada va en camino de serlo en cierto contexto: solucin
sencilla y rpida con consecuencias negativas a largo plazo.
Lecturas recomendadas:
J2EE AntiPatterns. Bill Dudney, Stephen Asbury, Joseph Krozak, and
Kevin Wittkopf. Ed. John Wiley & Sons, 2003. ISBN: 0471146153.
Antipatterns: Refactoring Software, Architectures, and Projects in
Crisis. William J. Brown. Ed. John Wiley & Sons, 1998. ISBN:
0471197130.
Antipatterns in Project Management. William J. Brown. Ed. John Wiley
& Sons, 2000. ISBN: 0471363669
