Cómo corregir código defectuoso de un freelancer

Cómo corregir el código defectuoso entregado por un freelancer

El código roto es molesto. También sale caro, porque cada hora que se pasa adivinando es una hora que no se dedica a sacar el trabajo adelante. Si un freelancer entrega una compilación que falla al cargar, rompe el proceso de compra o pasa las pruebas locales pero falla en staging, la vía más rápida no es entrar en pánico. Es recuperar el control y entender primero qué hacer si un freelancer entrega código roto. El primer paso es sencillo: evitar que el daño se propague y luego reunir hechos antes de que nadie empiece a discutir sobre quién causó qué.

1. Congela la versión dañada y conserva las pruebas

Pausa los despliegues. Si el código defectuoso ya está en producción, congela la versión actual, anota el commit exacto o la etiqueta de la versión y detén cualquier canal automático que pueda sobrescribir las pruebas. Un despliegue imprudente puede borrar justo el error que necesitas revisar.

Guarda el estado fallido. Haz capturas de pantalla, copia la salida de la consola, exporta los registros y conserva la instantánea de la base de datos si el problema afecta a los datos. Aquí importa la marca de tiempo. También el nombre del entorno. Si el fallo solo aparece en staging a las 14:20 después de ejecutar un script de inicialización, ese detalle no es adorno; es la diferencia entre una corrección de 10 minutos y una búsqueda a ciegas.

No “limpies” el sistema primero. Esa tentación arruina las pruebas. Un desarrollador puede corregir un módulo roto mucho más rápido cuando la traza del error, la respuesta del servidor y la última versión buena todavía están intactas. Si usas un sistema de tickets, adjunta los registros de inmediato y etiqueta el problema con el número de versión. La misma regla aparece en las reglas de colocación y visualización: mantén los registros claros, porque la confusión cuesta tiempo.

2. Clasifica el fallo por alcance, riesgo e impacto en el negocio

No todos los fallos son iguales. Un error tipográfico en un enlace del pie de página es un defecto. Un flujo de pago que pierde pedidos es un bloqueo. Un filtro de panel que falla y afecta a un equipo, pero no a los clientes, puede quedar en un punto intermedio. Tu trabajo es ordenar el daño por alcance antes de que el freelancer empiece a parchear piezas al azar, porque así también avanzas más rápido en cómo revisar el código entregado por un freelancer.

Hazte tres preguntas. ¿Qué funcionalidad está bloqueada? ¿Afecta a producción? ¿Pueden los usuarios seguir completando la tarea principal? Si la respuesta a la última pregunta es “no”, trátalo como un bloqueo de lanzamiento. Si la funcionalidad funciona pero falla un caso límite, puede ser una regresión parcial. Si el problema solo aparece en un informe no crítico, normalmente puede esperar. Esa clasificación cambia la velocidad con la que necesitas actuar y si el freelancer debe dejar todo lo demás.

El impacto en el negocio no es una sensación vaga. Debe estar ligado a algo concreto que puedas señalar: pedidos perdidos, registro roto, datos corrompidos o una cola de soporte que aumentó en 30 tickets. Los números ayudan. También ayuda nombrar al grupo de clientes afectado. Un error que afecta a 2 administradores internos no es lo mismo que uno que impide a 200 compradores finalizar la compra.

3. Separa los entregables reales de las correcciones posteriores

Aquí es donde muchos proyectos se complican. El freelancer puede haber entregado una funcionalidad, y el código roto puede revelar un segundo problema que nunca estuvo dentro del alcance. No son lo mismo. El entregable original es lo que se acordó en el briefing. Todo lo que aparezca después puede ser una corrección posterior, mantenimiento o una tarea nueva.

Revisa el alcance original línea por línea. Si se contrató al freelancer para crear un formulario de contacto, entonces una regla de validación rota dentro de ese formulario forma parte de la entrega. Si ese mismo formulario ahora necesita un nuevo filtro antispam, eso es una solicitud aparte. Mantén clara la diferencia. Evita que el alcance se desplace y te ayuda a asignar responsabilidades sin convertir cada defecto en un debate.

Una prueba práctica es esta: ¿el problema existiría si la funcionalidad se hubiera construido correctamente desde el principio? Si la respuesta es sí, probablemente pertenece a la entrega. Si el problema solo apareció porque tu equipo cambió el CMS, la API o el tema después de la entrega, entonces la reparación puede corresponder a correcciones posteriores y no al trabajo original del freelancer. Esa línea importa porque de ella depende una entrega limpia. Si gestionas ayuda externa con frecuencia, el artículo sobre migrar un proyecto de un estudio web a un freelancer resulta útil para entender dónde cambia la responsabilidad.

4. Haz una revisión rápida del código antes de pedir cambios

No hace falta ser un ingeniero senior para hacer una revisión útil del código. Sí hace falta paciencia para fijarse en los detalles. Empieza por lo evidente: ¿el freelancer enlazó la variable de entorno equivocada, olvidó un return o conectó el endpoint incorrecto? Ese tipo de errores puede romper una funcionalidad sin afectar a todo el sistema.

Luego revisa los puntos de integración. Mucho código roto no viene de la incompetencia, sino de un desajuste: el frontend espera JSON y el backend devuelve HTML; el módulo de pagos espera una clave real y el repositorio contiene una clave de pruebas; el nuevo widget asume un campo llamado customer_id, pero la base de datos guarda client_id. Un solo desajuste puede provocar un fallo que parece más grande de lo que es.

Busca también pruebas que falten. Si el freelancer añadió lógica sin un archivo de pruebas, el riesgo aumenta. Si hay pruebas, pero solo fallan en un navegador o en una versión de servidor, eso te dice algo concreto sobre el fallo. Una revisión rápida del código también puede revelar problemas de arquitectura, como una función que hace demasiado en un solo lugar. Eso es una señal de alerta, porque un parche simple puede ocultar un defecto más profundo.

Toma notas mientras inspeccionas. Marca cada hallazgo con un número de línea o una ruta de archivo. Una revisión de código adecuada no necesita dramatismo. Necesita trazabilidad. Si después pides una corrección, tus notas harán la conversación más breve y la reparación menos caótica.

5. Diseña un plan de corrección con opciones de rollback, parche o reestructuración

Ahora decide cómo recuperarte. Normalmente hay cuatro caminos: parchear el defecto, hacer un rollback parcial de la zona rota, revertir por completo la versión o rehacer el módulo. Cada camino tiene un coste distinto. Cada uno también tiene un perfil de riesgo diferente.

Un parche mínimo es la opción correcta cuando el error es estrecho, aislado y está bien entendido. Si un solo operador de comparación rompe una regla de descuento, parchea eso. Un rollback parcial funciona cuando una nueva funcionalidad es estable y otra no, de modo que puedes conservar la parte estable mientras eliminas el daño. Revertir por completo es más seguro cuando la versión tocó pagos, accesos o escrituras de datos y el sistema es inestable. Rehacer es la opción pesada. Úsala cuando la estructura esté tan rota que parchearla solo haga el código más difícil de mantener después.

Elige por las consecuencias, no por orgullo. Un parche apresurado que mantiene producción viva durante una hora pero provoca tres fallos más mañana no es una victoria. Un rollback más limpio puede parecer más lento, pero puede evitar que el equipo de soporte pase dos días respondiendo la misma queja. Si el freelancer está disponible, pídele un plan con una vía principal y una de respaldo. Esa es una conversación mejor que “solo arréglalo”.

6. Solicita correcciones de errores concretas con pasos de reproducción precisos

Envía una solicitud que un desarrollador pueda ejecutar sin adivinar nada. Las mejores solicitudes de corrección incluyen cinco elementos: pasos exactos para reproducirlo, comportamiento esperado, comportamiento real, entorno afectado y criterios de aceptación. Si falta uno de ellos, el freelancer perderá tiempo haciendo preguntas de seguimiento.

Escribe los pasos de reproducción como si alguien nunca hubiera visto el proyecto. Por ejemplo: “Abre Chrome 128 en staging, inicia sesión como administrador, abre la página de facturas, haz clic en Exportar y la página devuelve un error 500”. Eso es mucho mejor que “la exportación no funciona”. La primera versión se puede probar. La segunda invita a una conversación larga.

Incluye los detalles del entorno que importan. Un fallo puede aparecer solo en Safari móvil, en PHP 8.2 o después de refrescar la caché. Si el proyecto tiene varios entornos, nombra el que sufrió el problema. Una sola palabra como “producción” no basta si el error solo apareció en una región o después de una ventana de despliegue concreta. La precisión ahorra rondas de mensajes.

Indica los criterios de aceptación en lenguaje claro. Por ejemplo: “El botón de exportación debe generar el archivo CSV, la solicitud debe devolver 200 y no debe aparecer ningún error en la consola”. Eso le da al freelancer un objetivo y a ti una forma de probar el resultado sin ambigüedad. Si además necesitas un punto de referencia sobre cómo deben gestionarse la colocación y la exposición en los activos del proyecto, la página sobre las reglas de colocación y visualización es relevante.

7. Verifica el código corregido antes de cerrar el problema

No cierres el ticket solo por confianza. Vuelve a probar la ruta corregida y después prueba las rutas cercanas. Una reparación de una pantalla de pago puede romper fácilmente la pantalla del código de descuento si ambas comparten la misma función auxiliar. Por eso la verificación necesita al menos dos capas: el caso exacto que fallaba y uno adyacente.

Repite los pasos originales de reproducción. Si el error ya no aparece, comprueba si hay regresiones en la misma zona. Abre la consola del navegador, repite la solicitud de la API y confirma que los registros del servidor estén limpios. Si tu equipo tiene pruebas, ejecútalas. Si el freelancer añadió nuevas pruebas junto con la corrección, revísalas también. Una solución que pasa una vez pero falla con una segunda entrada no está terminada.

Vigila los efectos secundarios. Un parche que resuelve un error de índice puede cambiar silenciosamente el orden de clasificación. Un rollback puede restaurar una función y desactivar otra. Por eso la verificación no debe detenerse en “parece que está bien”. Debe incluir el seguimiento de la revisión de código, una comparación rápida con el problema original y una pasada final por la ruta de usuario que no debía cambiar.

Si la corrección llega a producción, sigue monitorizando al menos durante un ciclo de lanzamiento. Las primeras 24 horas después de un arreglo suelen revelar si el cambio realmente se sostuvo. Un informe de código roto cerrado demasiado pronto suele volver como un segundo ticket.

8. Documenta la entrega para el mantenimiento futuro

Registra qué se rompió, qué cambió y qué sigue abierto. Ese registro no necesita ser largo, pero sí debe incluir nombres, fechas y referencias de archivos. Un futuro freelancer debería poder leerlo y entender por qué se parcheó una función, por qué se eligió un rollback o por qué se dejó intacto un módulo.

Las buenas notas de entrega deben incluir la etiqueta de versión, el enlace al problema, los pasos de reproducción, el camino de corrección elegido y cualquier resultado de prueba. Si el freelancer hizo una solución provisional en lugar de una reparación permanente, indícalo. Si otro equipo se encargará de la siguiente ronda de correcciones, escríbelo con claridad. De lo contrario, el mismo problema se redescubrirá tres semanas después por alguien nuevo.

Mantén las notas prácticas. “El inicio de sesión se rompió después de la actualización del carrito” es demasiado vago. “El inicio de sesión falló solo en staging después de la actualización del carrito porque la URL de devolución de llamada de autenticación cambió en el commit 48a1c2” es el tipo de detalle que ahorra tiempo más adelante. Los números y los IDs de commit importan más que una explicación pulida.

Un último hábito ayuda más de lo que la gente espera: guarda los comentarios finales de la revisión de código junto con el ticket. Un futuro mantenedor podrá ver por qué se aceptó la corrección, qué comprobaciones pasaron y qué caso límite se dejó para una tarea posterior. Eso resulta útil la próxima vez que vuelva el mismo freelancer, o cuando un nuevo desarrollador herede el proyecto y solo tenga una tarde para leer la historia.