Hey devs, bienvenidos, nos ponemos picantes pero maduros.

Cuando sales de la universidad o de un bootcamp, sales con ganas de comerte el mundo. Te lees el libro de Design Patterns de la mítica "Gang of Four" (GoF), descubres los principios SOLID y automáticamente quieres aplicarlos en cada línea de código que tocas. Sientes que si tu solución no incluye un Abstract Factory, un Mediator y tres niveles de herencia, no eres un verdadero ingeniero.

No estoy diciendo que está mal leer ese libro o aplicar principios por si acaso! De hecho, yo mismo lo he leído y lo recomiendo tanto en mi trabajo como cuando dicto clases. Lo que digo es que no abuses de ellos; mejor sigue leyendo…

Luego pasan los años. Te toca mantener tu propio código un viernes a las 7 de la noche mientras producción se cae a pedazos. Es ahí, en el barro, donde el dogmatismo se cura jajaja.

Aquí te mostraré tres cositas que, por pura supervivencia, dejas de hacer cuando alcanzas la madurez en esta profesión.

1. Dejas de crear interfaces para clases con una sola implementación

El clásico reflejo de programador .NET: crear IUserService y su única implementación UserService. Si le preguntas por qué lo hace, te dirá: "Ah, es por si hay que cambiar la implementación en el futuro" o "Para poder hacer mocking en pruebas unitarias".

La realidad del futuro: En muchos proyectos, esa interfaz nunca tendrá una segunda implementación. Solo has duplicado la cantidad de archivos que tienes que abrir para leer un método.

La realidad del testeo: Hoy en día, la necesidad de usar interfaces únicamente para facilitar el mocking es mucho menor que hace unos años. Las librerías modernas permiten mockear clases concretas en muchos escenarios y, además, cada vez es más común apoyarse en tests de integración usando contenedores efímeros con Testcontainers para validar el comportamiento real del sistema.

Si solo hay una forma de hacer las cosas, usa una clase concreta. Si el negocio cambia y realmente aparece la necesidad de múltiples implementaciones, las herramientas de refactorización modernas suelen hacer que extraer una interfaz sea una tarea sencilla.

2. Le pierdes el miedo a duplicar código (a veces)

Nos grabaron a fuego el principio DRY (Don't Repeat Yourself). Nos dijeron que ver dos bloques de código similares era un pecado capital. ¿Qué hace el dev nuevo? Une esos dos bloques creando una abstracción hipercompleja con parámetros opcionales, genéricos y condicionales para que sirva para ambos casos por si acaso...

A los 30+ entiendes que es mucho más barato duplicar tres líneas de código que vivir atrapado en una mala abstracción. Si dos módulos distintos hacen algo parecido pero pertenecen a contextos de negocio diferentes, duplica el código. Si los unificas, el día que el módulo A necesite un cambio, vas a romper el módulo B sin darte cuenta. El acoplamiento prematuro es el verdadero enemigo, no la duplicación menor.

3. Dejas de optimizar antes de tiempo

Pasar tres días configurando un sistema de caché con Redis y políticas de invalidación complejas para un endpoint que consume un cliente interno dos veces al día no es ingeniería; es perder el tiempo y recursos.

Un senior escribe el código más simple, legible y directo posible. Monitorea en producción con OpenTelemetry, Datadog o Application Insights y, solo cuando las métricas demuestran que hay un cuello de botella real, se sienta a optimizar. En muchos proyectos, el tiempo del equipo termina siendo más costoso que el hardware o la infraestructura necesaria para resolver un problema de rendimiento que todavía no existe.

En resumen: Menos ego, más legibilidad

A los 20 solemos programar para que el código luzca vistoso y quedes bien. A los 30 programas pensando en que el tipo que va a mantener tu código en seis meses sabe dónde vives, y muy probablemente ese tipo seas tú mismo del futuro, así que lo haces mantenible y pragmático.

La verdadera elegancia no es la complejidad, es lograr que un problema difícil se resuelva con un código tan aburrido y obvio que cualquiera lo entienda a la primera.

Y antes de que alguien saque el teclado para decir "entonces SOLID está muerto" o "¿estás promoviendo malas prácticas?", no. Los principios de diseño siguen siendo herramientas extraordinarias cuando resuelven un problema real. El objetivo no es dejar de aplicar buenas prácticas, sino dejar de aplicarlas por inercia. Una mala abstracción suele ser peor que ninguna abstracción, pero una buena abstracción, introducida en el momento adecuado, sigue siendo una de las mejores inversiones que puedes hacer en la mantenibilidad de un sistema.

Si esta entrada te ha gustado mi crack, compártela 🙌

Créditos de imagen de portada: Foto de Eliott Reyna en Unsplash