Jesús L.C. – Apuntes de un aprendiz

En código, refactorizar suele ser relativamente “barato”: cambias nombres, ejecutas tests, despliegas… y listo. ahora con la IA mucho más. El problema es que en base de datos no. Ahí estamos tocando estado compartido, múltiples consumidores, queries ad-hoc, integraciones externas y, muchas veces, código que ni sabes que existe.

Por eso el refactoring en bases de datos es distinto: no solo tienes que mantener el comportamiento, también la compatibilidad en caliente. Y aquí es donde metemos la pata.

El error clásico: hacer un rename column

Imagina que tenemos una aplicación con su base de datos y su tabla users que tiene las tipicas columnas: id, email, name, surname, is_valid, created_at,

Ahora queremos cambiar de name a full_name

La solución naive:

ALTER TABLE users RENAME COLUMN name TO full_name;

Creamos la migración, subimos a producción ¿qué puede salir mal?
Todo:
– Código backend que no se ha actualizado
– Queries olvidadas
– Scripts de reporting
– Jobs batch
– Integraciones externas
– Dashboards
– Stored procedures

El problema no es el cambio en sí, es el acoplamiento invisible. Un simple rename puede romper medio sistema sin darnos cuenta.

La alternativa es Small Safe Step (3S)

Soy fan de este workshop de Edu Ferro lo he facilitado varias veces tanto internamente trabajando como en algún meetup. La idea del workshop es simple En lugar de un cambio grande, aplicamos pequeños pasos seguros.

Esto no es solo una técnica, es una mentalidad: reduce el riesgo al mínimo en cada paso

Este enfoque encaja perfectamente con los principios lean: batch pequeño, feedback rápido, reversibilidad.

Cómo hacerlo de forma segura

El patrón clásico (y probado):

1. Añadimos la nueva columna

ALTER TABLE users ADD COLUMN full_name TEXT;

Nada se rompe. Nadie depende aún de ella. Es un cambio pequeño y seguro.

2. Escribimos en ambas columnas (dual write)

Actualiza tu código:

$user->name = $fullName;
$user->full_name = $fullName;

Ahora tienes consistencia hacia adelante.

3. Sincronizamos datos históricos

Backfill:

UPDATE users SET full_name = name WHERE full_name IS NULL;

En sistemas grandes, esto se hace puede hacer en batches o en horas donde no hay demasiado tráfico. Por ejemplo algo añadiendo WHERE id BETWEEN 1 AND 1000; y haciéndolo iterativamente.

4. Leemos desde la nueva columna

Cambiamos el código para que use full_name.

Pero mantenemos la antigua por compatibilidad. Porque tenemos en mente que queremos cambios pequeños, seguros y sobre todo reversibles

5. Observamos (de verdad)

Este paso suele ignorarse. Pero es importante mirar, Log, Métricas, Queries, Errores,

¿Alguien sigue usando name?

Si sí → no borres nada todavía. Tenemos tiempo de cambiar donde se esté usando de forma tranquila, sin agobios, sin incidentes.

6. Eliminamos la columna antigua

Cuando estemos seguros:

ALTER TABLE users DROP COLUMN name;

Ahora sí. Ya hemos «renombrado» la columna

¿Por qué funciona este enfoque?

Porque cumple 3 propiedades clave:

1. Es reversible: Cada paso se puede deshacer. Un rename column no.

2. Mantiene el sistema siempre funcionando: Nunca rompes compatibilidad. Esto es clave en sistemas en producción.

3. Reduce el radio de impacto: En lugar de un cambio grande y arriesgado: muchos cambios pequeños y controlados

Esto es exactamente lo que promueve el libro de Refactoring Databases: evolucionar el esquema sin romper nada. Refactorizar una base de datos no va de SQL.

Va de gestionar riesgo en sistemas vivos.

Por eso: Si nuestro cambio no se puede desplegar sin miedo… probablemente no está bien diseñado. Además lo mejor de todo es que no hay 1 sola solución, en cada paso del camino podemos elegir que es lo mejor en ese momento.

Más casos donde aplicar el patrón

Este rename column es solo la punta del iceberg, este patrón se puede aplicar a muchos otros casos que seguro que tenemos en nuestro día a día. Aquí tenemos algunos otros ejemplos:

1. Cambiar tipo de dato
Ejemplo: cambiar el tipo de dato de: INT → UUID

2. Dividir una columna
Ejemplo: full_name → first_name + last_name

El cambio sería el mismo patrón:
Añadir columnas nuevas
Parsear datos existentes
Dual write
Migrar lecturas

2. Mover datos a una nueva tabla
Ejemplo: users.address → tabla addresses

La idea importante

Refactorizar bases de datos no va de SQL. Va de esto:

Diseñar cambios que puedan convivir con versiones antiguas del sistema.
Pensar en “flujo”, no en “operaciones”

Aquí es donde cambia el mindset. En sistemas que necesitan estar uptime siempre, no «haces migraciones», sino que diseñamos los cambios como procesos continuos que transforman datos poco a poco. En vez de pensar: “Tengo que migrar esta columna” Pensamos en “Como ir moviendo el sistema hacia el nuevo modelo sin que nadie lo note”

Uno de los errores más comunes es querer terminar rápido. Pero en producción, la velocidad óptima no es la máxima. Es la que no interfiere con el sistema, la que nadie nota. Por eso todos estos pasos

Lo que no se suele decir

Todo este enfoque no es gratis. Significa:

• Más código temporal (dual write, feature flags…)
• Más tiempo hasta “terminar” el cambio
• Más complejidad mental durante unos días o semanas

Y aquí siempre tenemos la tentación de “Para este cambio pequeño, hago un rename y ya está”. Y a veces es lo mejor. Aquí es donde tenemos que evaluar el coste/beneficio y ver que es lo que necesitamos en cada momento.

Hay veces que llega eso de: aquí siempre lo hemos hecho así y no ha pasado nada. Lo que tenemos que evaluar es que ocurre cuando sí pasa: afecta a los clientes, a la seguridad, a la credibilidad porque el sistema está fallando,…

El punto sutil: esto también es cultura de equipo

Esto no va solo de saber hacerlo, de dar muchos pasos. Va de que en el equipo entendamos que: ir más despacio al principio es ir más rápido a largo plazo, los cambios seguros no son opcionales en producción. Cuando esto de los small safe steps se convierte en norma, pasan cosas muy interesantes: desaparece el miedo a tocar la base de datos, los cambios se vuelven rutinarios

Si te quieres quedar con algo muy accionable, sería esto:

Cualquier cambio que no puedas desplegar en horario laboral sin miedo… necesita dividirse más.

Es una regla simple, pero muy potente.

Conclusiones

Refactorizar bases de datos no es tan inmediato como cambiar código, no es tan limpio y, desde luego, no es tan rápido. Pero precisamente por eso es donde se nota la diferencia entre un equipo que “saca cosas” y un equipo que construye sistemas que duran.

Un rename column no es malo en sí. Lo peligroso es hacerlo de golpe, sin red de seguridad, sin visibilidad y sin capacidad de volver atrás.

Cuando trabajamos con small safe steps cambiamos completamente el juego:

• Convertimos cambios arriesgados en procesos controlados
• Cambiamos miedo por observabilidad
• Sustituimos “cruzar los dedos” por iteración y aprendizaje

Y, sobre todo, ganamos algo muy valioso en producción: tranquilidad.

Porque cuando llegamos ahí, a esa tranquilidad es cuando de verdad estamos haciendo las cosas guay.