Photo by Brands&People on Unsplash

Lo que nadie te dice sobre el código que funciona en conferencias vs. el código que sobrevive en producción

Llevo más de cinco años en el equipo de baseline. Para quienes no lo sepan, baseline es ese equipo al que nadie quiere pertenecer pero que todos necesitan: somos los que arreglamos lo que se rompe en producción. Los hotfixes de madrugada. Los parches de emergencia. Los que destapamos las tuberías cuando el sistema se tapa.

Y desde aquí, desde esta trinchera poco glamorosa, he aprendido algo importante: existe una desconexión entre el código que impresiona en las demos y el código que realmente sostiene un negocio en el tiempo.

La paradoja del desarrollador con experiencia

He visto presentaciones brillantes. Charlas internacionales. Código que en la superficie se ve moderno, que usa los frameworks de moda, que hasta tiene tests. Y luego, meses después, ese mismo código llega como un ticket crítico de producción.

Cuando revisas el código detrás de esas features, a veces encuentras patrones como este:

if condicion1 {
    let service = NetworkService()
    service.fetchData()
} else if condicion2 {
    let service = NetworkService()
    service.fetchOtherData()
} else if condicion3 {
    let service = NetworkService()
    service.fetchMoreData()
}
// ... y así por varios niveles más

IFs anidados que crecen con cada nueva condición. Servicios duplicados en cada rama. Lógica repetida una y otra vez. Y cuando intentas escribir pruebas unitarias, te topas con singletons por todos lados que hacen imposible aislar comportamiento.

Y lo interesante es que esto no proviene de juniors sin experiencia. Proviene de desarrolladores con años en la industria.

Lo que realmente significa “experiencia”

Aquí está la reflexión incómoda: años de experiencia no garantizan automáticamente código escalable, modular, legible y simple.

¿Por qué? Porque muchas veces esa experiencia se construyó sobre la urgencia de entregar features, no sobre la práctica deliberada de fundamentos de ingeniería.

Y los fundamentos importan. No son teoría académica ni lujos intelectuales. Son la diferencia entre:

• Abstracción vs. duplicación: Reconocer patrones y extraerlos en vez de copiar-pegar lógica
• Encapsulación vs. estado global: Pasar dependencias por parámetros en vez de tener singletons compartidos imposibles de testear
• Simplicidad vs. complejidad accidental: Eliminar objetos redundantes que no agregan valor, solo ruido

He notado que cuando estos fundamentos no están sólidos, no importa cuántos años lleves programando o en qué stack trabajes. Las estructuras de datos, los algoritmos, los principios de diseño — esas cosas “aburridas” que a veces relegamos — terminan siendo las que marcan la diferencia entre código que escala y código que se convierte en deuda técnica.

El verdadero costo del código complejo

Cada vez que veo código innecesariamente complejo, veo costos reales que alguien va a pagar eventualmente:

• Más código que probar: Esos múltiples niveles de condicionales necesitan muchas más combinaciones de pruebas
• Más código que leer: Un desarrollador nuevo tarda mucho más en entender qué hace cada rama
• Un proyecto más pesado: Servicios duplicados, objetos redundantes, dependencias innecesarias
• Más errores: Cada duplicación es una oportunidad de inconsistencia

Y el peor costo de todos: mantenibilidad.

Ese código que funcionó perfecto en la demo se convierte en un reto para el equipo que tiene que mantenerlo seis meses después.

Lo que he aprendido desde baseline

Si algo me ha enseñado estar en este equipo es esto: el código hay que hacerlo lo más simple que se pueda.

No es pereza. No es falta de ambición. Es ingeniería consciente.

Un sistema simple es:

• Más fácil de razonar
• Más fácil de probar
• Más fácil de cambiar
• Más difícil de romper

Cuando te toca mantener código de otros (incluyendo el tuyo de hace seis meses), aprendes rápido que

“La elegancia no está en usar el patrón más sofisticado o el framework más nuevo. Está en escribir código que otro humano pueda entender sin tu ayuda.”

Cómo enfrento el problema: Divide y vencerás

Ahora bien, criticar es fácil. Lo difícil es resolver estos problemas cuando llegas a un proyecto con deuda técnica acumulada y producción presionando por fixes urgentes.

Mi enfoque es pragmático: divide y vencerás.

Cuando llega un ticket crítico:

1. El parche primero Producción necesita estabilidad ya. Hago el fix mínimo necesario para que el sistema funcione. No es el momento de refactorizar todo el módulo.

2. Las pruebas después Una vez que el parche funciona, escribo las pruebas que deberían haber existido desde el principio. Esto me da una red de seguridad para lo que viene.

3. El refactor incremental Aquí está la clave: después de la entrega, hago el refactor correspondiente pantalla por pantalla.

No intento arreglar todo el proyecto de golpe. Eso es una receta para el fracaso. En cambio:

• Tomo la pantalla o módulo que acabo de arreglar
• Aplico los patrones de diseño apropiados
• Muevo el código legacy a una carpeta /legacy
• Migro funcionalidad poco a poco hasta que esa carpeta queda vacía

Es un proceso gradual. A veces toma semanas. Pero es sostenible y no bloquea a nadie.

El poder de la carpeta /legacy

Crear esa carpeta /legacy fue uno de los mejores cambios de proceso que hice. Te permite:

• Visualizar el progreso: Ves claramente cuánto código viejo queda por migrar
• Trabajar sin miedo: El código antiguo sigue ahí si algo sale mal
• Mantener momentum: Cada pantalla migrada es una victoria pequeña pero concreta
• Comunicar avance: Es fácil mostrarle al equipo: “Esta semana vaciamos la carpeta del módulo de autenticación”

No es glamoroso. No vas a dar una charla sobre “cómo creé una carpeta legacy”. Pero funciona.

Una invitación a la reflexión

Esto no es una crítica a quienes dan charlas o construyen presencia en redes. De hecho, compartir conocimiento es algo que respeto profundamente y que yo mismo quiero hacer más.

Pero es una invitación a reflexionar: la visibilidad no valida automáticamente la calidad técnica. Las demos muestran el momento del éxito, no siempre el código que lo sostiene. Los likes en LinkedIn no debuggean producción.

Si estás construyendo tu carrera como desarrollador: los fundamentos importan más de lo que parece.

Aprende abstracción. Practica encapsulación. Valora la simplicidad. Escribe código que sea fácil de cambiar, no solo fácil de escribir.

Y si ya estás en una posición donde tienes que mantener código complejo: recuerda que no tienes que arreglarlo todo de una vez. Divide y vencerás. Un módulo a la vez. Una pantalla a la vez.

Porque tarde o temprano, todo código termina en producción. Y ahí es donde se ve la diferencia entre experiencia acumulada y maestría técnica.

¿Has trabajado manteniendo código legado o arreglando producción? ¿Qué estrategias te han funcionado? Me encantaría leer tu perspectiva en los comentarios.