Bit veo, bit quiero

Bit veo, bit quiero

Hasta la llegada de la programación orientada a objetos, el desarrollo era bastante sencillo en términos de arquitectura o diseño. C o ensamblador no daban mucho más juego que unos algoritmos de optimización para árboles binarios o listas enlazadas. Con la llegada de la programación orientada a objetos, este hecho empezó a cambiar. Llegaron los patrones de diseño…

ByteHasta la llegada de la programación orientada a objetos el desarrollo era bastante sencillo en términos de arquitectura o diseño, C o ensamblador no daban mucho más juego que unos algoritmos de optimización para árboles binarios o listas enlazadas.

Con la llegada de la programación orientada a objetos este hecho empezó a cambiar, llegaron los patrones de diseño, los paradigmas de programación, GoF, … el diseño orientado a objetos se volvió tan amplio, y tan fácil de explotar la creatividad del programador, que de repente era fácil elaborar una nueva idea o un nuevo patrón de software.

Como todo lo novedoso en algunos casos se desvirtuó un poco, en los 80 y 90 la sobrearquitectura pobló los diseños, aplicaciones orientadas a la “gran arquitectura”, capaces de absorber cualquier requisito y preparadas incluso para desarrollos poco probables en el tiempo.

Finalmente se vio que el ciclo de vida de ciertas aplicaciones no es tan largo, que la sobrearquitectura poblada de clases abstractas interfaces y herencia no siempre iba a ser utilizada o siquiera útil. Que diseñar un rascacielos para almacenar una caja de zapatos quizás era extralimitar el concepto del diseño. Que el concepto del “por si acaso” no aplica, que hay cosas que si no son probables que pasen, simplemente, no suceden.

Esta idea ha sido correctamente elaborada en conceptos como KISS o DRY, pero acercando un poco más el foco se puede observar la cantidad de conceptos e ideas que constantemente surgen esporadicamente, muchas de ellas apenas perceptibles para el ojo crítico, más allá de las mencionadas otras muchas como “reutilización”, “refactorización”, “desacoplamiento”… existen infinidad de estas, en épocas pasadas el estilo era la sobrearquitectura, después el minimalismo KISS, DRY,… se pasa de la pesadez burocrática de CMMI a la agilidad y descaro de SCRUM.

Estas tendencias en ciertos casos calan en la comunidad informática, de hecho se produce un efecto contagio, unos poco lo esparcen y otros muchos lo labran, y de pronto un concepto en apariencia simple y lógico se convierte en dogma, y se menciona siempre que hay ocasión, la comunidad atiende y aplaude asombrada por el mero hecho, por ejemplo, de explicar con siglas que el código debe ser simple. Esporádicamente surgen personajes que comentan con gran profusión y detalle todos estos avances como si fuera el dogma de una nueva iglesia creada por la inocencia de unos pocos y la ignorancia de muchos.

Para sorpresa de propios y extraños la informática se ve sometida a las modas, que de forma cínica se cuelan en el colectivo enseñando ideas rescatadas del pasado, de antiguos tomos tan ajados que al no ser todavía escaneados y colgados en Internet resultan ignorados por las nuevas generaciones, volviendo como antiguas modas de forma remozada intentando resurgir como nuevos conceptos cuando realmente es una reformulación de un concepto obvio y olvidado.

Esto provoca espontaneos clamores en la comunidad al grito de “¡El código debe ser desacoplado!” “¡Refactorizemos!” como vítores en galeras, como conceptos contrapuestos expresados en gradas como aficiones rivales, como si solo existieran los conceptos del momento y no los pasados, sin posibilidad de fusión sino solamente de confrontación.

No todas las ideas deben ser enfrentadas. No solo la idea del momento es la correcta, no todo es válido en cualquier momento, no siempre el código debe ser “desacoplado” o “refactorizado”, el concepto existe en sí, pero como una ayuda no como una verdad absoluta que condicione o redirija cualquier desarrollo, el verdadero diseño orienta a la idea correcta, no al concepto predominante.

El tiempo enseña el concepto de la distancia, las ideas no se separan, simplemente se retuercen se estiran y se contraen para volver renovadas en una nueva forma, la historia enseña que muchas de estas ideas ya fueron tratadas, que darle un nuevo envoltorio no implica necesariamente un nuevo concepto o diseño, que clamar contra el viento ideas olvidadas no debería hacerlas más fuertes, que la creatividad diseña de cara el futuro pero el sentido común impera sobre el pasado.

Los conceptos pueden resurgir y las siglas pueden cambiar, lo que hoy se oye mañana también se oirá con otro nombre, la idea no pierde su valor ni debe perder su valor para el oyente sometido al concepto, bueno es conocerlo pero mejor es discriminarlo, conocer el origen de la idea, el concepto reformulado pero aún así conocido, no perder la capacidad de discriminación ni de encontrar la frase esencial en párrafos de divagación y poder decir que no hay más frases que leer, poder matar una idea y por ende crear otra nueva porque aunque resulte paradójico a veces las buena ideas vienen de conocer todas las anteriores y lo que podría ser una idea basada en el pasado se convierte en una idea surgida del pasado.

Yo, Arquitecto
Josu Uribe Sainz

 


 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies. Más información sobre nuestras cookies, siga este enlace

ACCEPT