¿Qué onda, colegas? El otro día estaba revisando un PR (Pull Request) de un microservicio que, en teoría, solo tenía que mover datos de un punto A a un punto B. Cuando lo abrí, casi me voy de espaldas: patrones de diseño hiper-complejos, inyección de dependencias hasta para saludar, y una abstracción tan profunda que sentí que estaba leyendo filosofía en lugar de código.
Me puse a pensar: ¿En qué momento decidimos que si el código no parece una ecuación de la NASA, no es buen código?
Hoy en día parece que nos da miedo escribir un simple if-else o un bucle for tradicional. Queremos meterle Kubernetes a un blog personal o usar Microfrontends para un formulario de contacto. ¡Relajémonos un poco!
El culto a la complejidad (o el ego del programador)
Fijate que a veces pecamos de querer usar la herramienta más “cool” solo porque la vimos en un hilo de Twitter. Si vienes de React, seguro has sentido la presión de meter Redux, Thunk, Saga y Context al mismo tiempo cuando un simple useState bastaba. O si programas en .NET o Java, a veces creamos 5 interfaces para una sola implementación “por si acaso” el cliente decide cambiar de base de datos mañana (Spoiler: Nunca pasa).
Esa “arquitectura del futuro” se convierte en la pesadilla del presente.
Dato para Ingenieros: La complejidad cognitiva de un proyecto aumenta exponencialmente con cada abstracción innecesaria. El código que no se entiende a simple vista es deuda técnica que todavía no has pagado.
El manifiesto del “Código Aburrido”
El código aburrido es ese que lo lees y decís: “Ah, ok, esto hace esto”. No hay trucos, no hay magia negra, no hay funciones de una sola línea que parecen jeroglíficos.
Si estás trabajando en un backend, por ejemplo, antes de meterle un “Clean Architecture” de libro con 20 carpetas para un simple CRUD, pensá en quién va a mantener eso en Navidad a las 2 de la mañana.
Quiero también dejar claro que no estoy en contra de las buenas prácticas de programación, al contrario, son fundamentales para el desarrollo de software de calidad. Sin embargo, es importante saber cuándo y cómo aplicarlas, sin caer en la sobreingeniería.
El camino “Cool” vs. El camino “Aburrido”
Imagina que queremos validar si un usuario es mayor de edad. El programador “over-engineer” que quiere impresionar a los de su oficina haría esto:
// El camino "over-engineered" (Dolor de cabeza gratuito)
import { ValidatorFactory } from "./factories/ValidatorFactory";
import { AgeStrategy } from "./strategies/AgeStrategy";
// Definición de tipos y contratos innecesarios para un check simple
interface ValidationResult {
isValid: boolean;
}
const userValidator = ValidatorFactory.create(new AgeStrategy());
const result: ValidationResult = userValidator.execute(user.age);Está de lujo el diseño, pero para el mundo real, el código aburrido (el que nos gusta a los que tenemos calle) gana por goleada:
// El camino senior: KISS (Keep It Simple, Stupid)
function isAdult(age: number): boolean {
if (age < 18) return false;
return true;
}¿Ves la diferencia? El segundo lo entiende hasta el de soporte técnico. El primero requiere que navegues por tres carpetas para entender qué diablos está pasando.
Menos es más (En serio)
Como desarrolladores Fullstack, tenemos que lidiar con demasiadas cosas: el estado en el frontend, las migraciones en el backend, el despliegue… Si a eso le sumas una lógica rebuscada, te vas a quemar (Burnout) antes de terminar el sprint.
Tip de Pro: Antes de agregar una librería nueva o un patrón de diseño complejo, hacete esta pregunta: “¿Podría explicarle este código a un Junior en menos de 2 minutos?”. Si la respuesta es no, borra y simplifica.
Beneficios de ser un programador “Aburrido”:
- Onboarding rápido: Los nuevos devs no tardan meses en entender el proyecto.
- Debug fácil: Menos capas significan menos lugares donde el error se puede esconder.
- Mantenimiento real: El código simple escala mejor porque es más fácil de refactorizar cuando los requerimientos de verdad cambian.
Conclusión
No me malinterpretes, las arquitecturas robustas tienen su lugar (si estás haciendo el motor de búsqueda de Google, dale con todo). Pero para la mayoría de nosotros, la simplicidad es el nivel más alto de sofisticación.
Nota mental: Tremenda frase de Leonardo da Vinci, ¿no? Como para tatuarsela en el antebrazo.
La simplicidad es el nivel más alto de sofisticación - Leonardo da Vinci
Volvamos a disfrutar de escribir código que simplemente funciona. Menos ego, más soluciones. Al final del día, al usuario no le importa si usaste un Abstract Singleton Proxy Factory, le importa que el sistema sea rápido y no se caiga.
¿Y vos qué opinas? ¿Te has sentido culpable por escribir código “demasiado simple” o sos de los que ama meterle 20 capas a todo “por si las moscas”? ¡Contame en los comentarios, que aquí estamos para aprender entre todos!
¿Te gustaría que escribiera sobre cómo identificar cuándo una abstracción SÍ es necesaria?