6 patrones de programación que aprendí de ingenieros senior

Al inicio de mi carrera, pensaba que los ingenieros senior eran mejores porque conocían más frameworks, más patrones de diseño y más soluciones avanzadas.

Con el tiempo entendí que esa no era la diferencia principal.

Los mejores ingenieros senior suelen escribir código simple, claro y hasta aburrido. Pero ese código es fácil de leer, fácil de probar y fácil de cambiar cuando el producto evoluciona.

El buen código no demuestra su valor solo cuando funciona hoy. Lo demuestra cuando cambian los requisitos, aparece un bug en producción o un nuevo desarrollador necesita entenderlo.

Estos son seis patrones de programación que aprendí de ingenieros senior.

1. Hacen que el camino feliz sea evidente

El código difícil suele mezclar validación, errores, base de datos, lógica de negocio y respuesta en una sola función.

Los ingenieros senior hacen que el flujo principal sea fácil de leer.

Primero manejan los casos inválidos. Después dejan que el camino principal se lea de arriba hacia abajo.

if (!user) {
  throw new Error("User is required");
}

if (!items.length) {
  throw new Error("Order must contain items");
}

const order = createOrder(user, items);
return order;

Este patrón reduce condiciones anidadas y hace que el código sea más fácil de depurar.

2. Nombran las cosas por su significado de negocio

Nombres como processData, handleItems o updateRecord no explican mucho.

Mejores nombres serían:

calculateInvoiceTotal()
markInvoiceAsPaid()
syncCustomerSubscriptions()

Un buen nombre explica la intención del código.

La regla es:

Nombra funciones y variables según el dominio del problema, no solo según la operación técnica.

3. Ponen las reglas importantes donde no puedan saltarse

Algunas reglas no deberían depender solo del código de aplicación.

Si un usuario no puede tener dos suscripciones al mismo plan, una simple consulta antes de insertar no siempre es suficiente. Con requests concurrentes, dos procesos pueden pasar la validación al mismo tiempo.

Una solución más fuerte es usar una restricción en la base de datos:

$table->unique(['user_id', 'plan_id']);

Después, la aplicación puede convertir ese error en una respuesta de validación clara.

La regla es:

Pon las reglas críticas en el límite más fuerte disponible.

4. Evitan arquitectura “por si acaso”

Muchos sistemas se vuelven complejos porque se construyen para futuros imaginarios.

Una funcionalidad simple termina con interfaces, factories, strategies, events y archivos de configuración.

Los ingenieros senior no ignoran el futuro, pero tampoco construyen una arquitectura completa para problemas que aún no existen.

La regla es:

No introduzcas una abstracción antes de que el código realmente la necesite.

La flexibilidad no viene de tener más capas. Viene de tener código claro que pueda cambiarse con seguridad.

5. Hacen visibles los efectos secundarios

Una función como esta parece simple:

updateUserProfile(user);

Pero puede actualizar la base de datos, limpiar caché, enviar emails, escribir logs o disparar eventos.

Cuando esos efectos están ocultos, los bugs son más difíciles de rastrear.

Una versión más clara sería:

updateUserProfile(user);
clearUserCache(user.id);
recordAuditLog(user);
dispatchProfileUpdatedEvent(user);

La regla es:

No escondas acciones importantes detrás de nombres inocentes.

6. Dejan el código más fácil de cambiar

Un desarrollador junior pregunta: ¿funciona?

Un ingeniero senior también pregunta: ¿será fácil cambiar esto después?

Esa diferencia importa.

Buen código no es solo código que pasa los tests. Es código que otro desarrollador puede entender y modificar con confianza.

Eso significa:

• evitar one-liners innecesariamente inteligentes;

• separar responsabilidades;

• no mezclar lógica de negocio con detalles de presentación;

• explicar el porqué cuando un comentario es necesario;

• pensar en el próximo cambio.

Conclusión

Los mejores patrones que aprendí de ingenieros senior no eran llamativos.

Eran simples:

• hacer visible el camino feliz;

• nombrar por significado;

• proteger reglas en límites fuertes;

• evitar arquitectura innecesaria;

• mostrar efectos secundarios;