Cómo saber si no te rompieron nada

Pedile dos cosas: la lista de lo que ya funcionaba antes de tocar nada, y esa misma lista comprobada después. Si no puede mostrártela, el cambio no está verificado — está mirado a ojo, que es otra cosa. Y lo digo por experiencia propia: me pasó a mí en este mismo sitio, con un control puesto.

Por qué «compila» y «se ve bien» no alcanzan

Estaba agregando una página nueva acá. Para integrarla había que tocar dos piezas que usan las ocho páginas del sitio: el menú de arriba y el botón que cambia de idioma. Antes de empezar puse un control: comprobar que los archivos de las dos páginas de inicio no cambiaran ni una línea. Si no cambian, razoné, no se pueden haber roto.

El razonamiento estaba mal. El cambio no estaba en esas páginas: estaba en dos piezas que ellas usan. Un archivo puede quedar intacto y comportarse distinto, porque lo que cambió es algo de lo que depende.

Lo que sí es una prueba

El arreglo no fue mirar con más atención: fue medir otra cosa. Ahora, antes de tocar nada, guardo a dónde llevan de verdad todos los enlaces de las páginas que ya funcionan —el logo, cada opción del menú, el cambio de idioma, el botón de contacto— y después del cambio los vuelvo a leer y los comparo uno por uno.

Y hay un segundo paso que no salteo nunca: rompo una pieza a propósito y compruebo que el control se pone en rojo. Si no se pone en rojo, el control no sirve, y lo arreglo antes de seguir.

Un control que se pone verde con el defecto puesto es peor que no tener control. No solo no avisa: te convence de que está todo bien.

Las tres respuestas que no son una verificación

• «Compila sin errores» — solo dice que el código es válido, no que haga lo correcto.
• «Ese archivo no lo toqué» — no dice nada si lo que cambió es algo de lo que ese archivo depende.
• «Mirá, se ve bien» — una captura no dice a dónde llevan los enlaces.

Las tres pueden ser ciertas con el sitio roto. Lo único que sirve es comparar el comportamiento contra cómo estaba antes, y demostrar que esa comparación es capaz de fallar.

Dónde te pega esto a vos

El caso más caro que conozco es el de una agencia de viajes que suma una sección al sitio y, sin que nadie lo note, deja el formulario de contacto sin funcionar. Nadie se entera: no aparece un error, aparece silencio. Las consultas simplemente dejan de llegar, y eso se descubre semanas después, contando cuántas entraron el mes pasado. Si trabajás con reservas y cotizaciones, en sistemas para agencias de viajes cuento cómo ordeno esa parte.

Lo mismo vale para cualquier cambio en algo que ya te está trayendo clientes: el riesgo no está en lo que se agrega, está en lo que se toca de paso.

La pregunta, en una línea

Cuando le encargues un cambio a alguien, la pregunta que más te conviene hacer no es cuánto tarda. Es: «¿cómo vas a comprobar que no rompiste lo que ya andaba, y cómo sé yo que esa comprobación funciona?».

Si te contesta con una lista concreta y con la prueba de que su control puede fallar, estás en buenas manos. Si te contesta «tranquilo, no toqué nada», anotá la fecha: vas a necesitarla.

Y si lo que viene no es un cambio suelto sino automatizar un proceso entero, hay otras cuatro preguntas que conviene tener a mano antes de arrancar: qué preguntar antes de automatizar.