Los patrones de diseño son probablemente el tema más discutido y menos comprendido en todo sistemas. La gente tiene sus propias opiniones y, sorprendentemente, todas difieren en una medida preocupante. Parece un tópico plenamente subjetivo, donde cada uno tiene su propia experiencia personal y laboral. Es un caso de estudio interesante porque en realidad los patrones de diseño son objetivos en sí. Pero antes de meternos en esta problemática, debemos entender a qué nos estamos enfrentando.
Definición Inicial
Los patrones de diseño o design patterns, son una solución general, reutilizable y aplicable a diferentes problemas de diseño de software. Se trata de plantillas que identifican problemas en el sistema y proporcionan soluciones apropiadas a problemas generales a los que se han enfrentado los desarrolladores durante un largo periodo de tiempo, a través de prueba y error. Fuente
Entendemos por patrón a algo que se repite, que se le puede seguir y replicar, aplicando los mismos pasos con el mismo (o similar) resultado. La prueba y error es fundamental para crear un patrón nuevo, porque nos indica un “camino hacia la perfección”, el cual quizá no se pueda alcanzar pero al menos se va acercando iteración tras iteración.
Su propósito es el de resolver problemas generales porque justamente fue testeado y corroborado en distintos proyectos a lo largo de los años. Y sigue siendo un patrón porque la solución no difiere demasiado (o en absoluto) en los proyectos aplicados. Esta pensado para convertirse en un estandar de implementación.
No entiendo.
El problema radica en que la explicación de este concepto siempre es difícil de asimilar. Usé palabras hermosas que me darían una charla en una universidad, pero salvo que seas alguien que ya conoce el concepto y la aplicación de los patrones en profundidad, es probable que no lo hayas entendido.
La mejor manera de entenderlo es en la práctica, asi que vamos a trabajar directamente sobre un caso de uso ficticio.
La desafortunada vida de Pepe, el desarrollador web
Pepe era un hombre de 30 años que vivía solo en un departamento de Recoleta (Buenos Aires, Argentina). Todos los días, luego de terminar su jornada laboral, salía a pasear a su caniche “Pepa” (no era muy original, no lo culpemos por esto) mientras pensaba en Mara v1.4.3, un proyecto que venía desarrollando hacía dos años.
Se trataba de una solución web basada en facilitar el proceso de envío que el correo con sus sistemas más precarios no podía cubrir. Tenía una parte frontend (una web para clientes que se querían inscribir y hacer seguimiento de paquetes) y una parte backend (una API que interactuaba con una base de datos enorme, la cual gestionaba tanto clientes de correo como empresas).
Cuando Pepe tomó este proyecto, no había nada documentado: No existía un arquitecto que definiera la solución en sí, solo definiciones funcionales de su empresa, la cual le daba la libertad absoluta de decidir la tecnología aplicable y su arquitectura correspondiente.
Mientras Pepa terminaba de hacer pis encima de las flores que pertenecían al vecino (el cual odiaba con bastante fervor), Pepe recordó con nostalgia los inicios de ese proyecto. Su extensa experiencia en PHP le permitió armar un flujo de tecnologías que se intercomunicaban entre sí y armar la parte de la API conectándola a MySQL como base de datos a través de consultas crudas (o raw) escritas en el código fuente.
Todo era felicidad y agilidad hasta que empezaron a pasar los años y el proyecto mutó y evolucionó: Ahora Pepe tenía mas de mil clases que se conectaban de formas muy similares; y cambiar algo era un suplicio. Tenía que tocar tantos archivos para un simple cambio, que sus estimaciones empezaron a dispararse. Al principio agregar un endpoint le llevaba un día, y ahora representaba una semana. El código era inmantenible.
Pepe empezó a trabajar horas extras sin decirle nada a su jefe. No podía explicar que la evolución del proyecto implicó el desastre del mismo. Había productos muchísimo más grandes en el mercado, e incluso en su propia empresa, los cuales publicaban mejoras constantes, semana tras semana. ¿Qué tenían ellos que él no? Decidió preguntarle a su compañero Pepino (si, asi se llamaba, no discriminen) al respecto.
Pepino le hizo una simple pregunta: ¿Qué patrones de diseño utiliza tu solución? Pepe no supo responder a esa pregunta. Volvió a su escritorio y empezó a investigar a fondo. Asi fue como se volvió un desgraciado: había desarrollado un producto durante dos años sin aplicar ningún patrón de diseño. Un proyecto que ya tenía más de mil clases repartidas por varias carpetas relevantes (en su momento); muchas llamadas a métodos repetidos y sentencias SQL hasta donde no llega el sol.
Mientras Pepe soltaba a Pepa para que corra en la plaza, se preguntaba qué le diría a su jefe cuando le pidió esa misma tarde que cambiara la base de datos. Fue algo como:
¡Buenos Dias Pepe! Consideramos que MySQL no es la BD ideal para esto, ¿cuánto te llevaría cambiar a postgresql?
Por la mente de Pepe apareció una estimación que asustaría a Lovecraft si siguiera vivo: Un año de cambios, con suerte.
Necesito una ración extra de patrones para llevar, por favor.
Querido lector, se muy bien que esperabas un final feliz. Algo como: Pepe aprendió patrones de diseño y cambió su vida por completo. Pero seamos realistas: cuando llevas tanto tiempo en un proyecto y los tiempos demandan, un cambio de este calibre requeriría un refactor completo del código.
Esto es solo posible cuando logramos convencer al cliente de que nuestra modificación (la cual va a llevar mucho tiempo, incluso con buenas prácticas) va a cambiar para bien el producto. Salvo que hablemos de performance o aumentar la rentabilidad; dudo que nuestro cliente quiera invertir en un proyecto que ya tuvo un costo de desarrollo determinado.
Entonces todo esto nos lleva a evitar la tragedia: Los patrones de diseño existen para evitar los casos de Pepe en todo el mundo. Necesitamos que nuestro código sea escalable, mantenible y flexible en el tiempo. Pensemos que existieron muchos desarrolladores cometiendo errores y poniendo a prueba diversos métodos; y entre fallos y aciertos, llegaron a una serie de conclusiones que nos beneficiaron a todos.
Usemos el presente a nuestro favor y utilicemos estas herramientas que nuestros antepasados con camisas blancas y anteojos más grandes que sus ojos nos dejaron a nosotros, los simples mortales.
Conclusiones
Ya nos quedó claro el concepto, pero todavía no tratamos con sus aplicaciones prácticas. En la próxima parte veremos en detalle los tipos de patrones que existen y sus implementaciones en proyectos reales.
¡Nos vemos!
Top comments (0)