Cómo asumir una base de código de otro equipo: los primeros 30 días

Heredar una base de código suele ocurrir en un mal momento. Terminó el contrato con la agencia, se fue el único ingeniero, o el producto creció más allá de las personas que lo construyeron. La presión es mostrar avances rápido, y el reflejo es empezar a entregar features o a planear una reescritura.

En el primer mes, ambas cosas son errores. Trabajar en sistemas heredados es caro (en la investigación de Stripe, los desarrolladores reportaron dedicar 17,3 horas de una semana de 41,1 horas a mantenimiento y código malo, Developer Coefficient, 2018), pero no puedes saber qué problemas importan hasta entender qué hace el sistema y dónde se rompe.

Este es el orden que recomiendo para cualquier traspaso: primero los accesos, luego el build, luego los flujos de ingresos, luego los riesgos. Funciona tanto si el equipo anterior todavía está disponible como si desapareció hace tiempo.

Días 1–3: ¿a qué necesitas tener acceso?

Antes de leer una línea de código, averigua quién controla el sistema. En los traspasos, los problemas más peligrosos rara vez están en el código; están en cuentas que pertenecen a alguien que ya no trabaja para ti.

Haz una lista de cada uno de estos elementos, de quién es el dueño hoy, y pásalos a nombre de la empresa:

Después, rota todos los secretos que el equipo anterior podía leer. No es una acusación, solo higiene: no puedes saber dónde terminaron las copias de las claves.

Semana 1: ¿puedes hacer el build y desplegarlo?

Tu primer objetivo técnico es aburrido y esencial: hacer el build del proyecto desde una máquina limpia y desplegar un cambio trivial con el proceso normal.

Anota cada paso a medida que avanzas. Variables de entorno faltantes, servicios sin documentar, un script que solo funciona en la laptop del desarrollador anterior: cada cosa que encuentres ahora habría sido un incidente más adelante. Al final de la semana deberías tener:

• Un README que lleve a un ingeniero nuevo desde el clone hasta la app funcionando.
• Un despliegue que pase por un pipeline, no hecho a mano.
• Un cambio mínimo (un ajuste de texto, una línea de log) desplegado en producción y verificado.

No entregues features esta semana, aunque alguien esté esperando una. Mientras no puedas desplegar con seguridad y revertir, cada feature es una apuesta con producción.

Semana 2: ¿qué hace realmente el sistema?

Ahora lee el sistema, empezando por lo que le importa al negocio y no por la estructura de carpetas. Identifica los flujos de ingresos: los flujos que, si se rompen, cuestan ingresos o confianza. En la mayoría de los productos eso significa registro, inicio de sesión, pago y la acción principal por la que pagan los clientes.

Para cada flujo de ingresos:

1. Síguelo por el código desde la pantalla hasta la base de datos y de vuelta.
2. Haz una lista de los servicios externos de los que depende.
3. Agrega monitoreo si no lo hay: seguimiento de errores y una métrica simple de tasa de éxito.

Al final de la semana deberías poder dibujar el sistema en una página: los componentes principales, los almacenes de datos, las integraciones y los flujos de ingresos que pasan por ellos. Esa página es el documento más valioso del traspaso, y muchas veces no existe.

Semanas 3–4: ¿dónde está el riesgo?

Con los accesos asegurados y los flujos de ingresos visibles, busca riesgos en un orden fijo, del más urgente al menos urgente:

1. Seguridad. Dependencias desactualizadas con vulnerabilidades conocidas, secretos en el repositorio, falta de controles de autorización en endpoints sensibles, buckets de storage públicos.
2. Datos. Backups que existen y que realmente se pueden restaurar (prueba uno), migraciones versionadas, datos personales guardados donde no deberían estar.
3. Errores en producción. Los diez errores más frecuentes. Los sistemas heredados suelen tener un ruido constante de fallos que nadie mira.
4. Pruebas en los flujos de ingresos. Si no hay ninguna, escribe algunas pruebas end-to-end para los flujos de la semana 2 antes de cambiarlos.
5. Rendimiento. Consultas y páginas lentas en los flujos de ingresos, no en todas partes.

Mantén una lista escrita, ordenada por impacto y esfuerzo. Se convierte en el plan del próximo trimestre y en la evidencia para cualquier decisión más grande.

¿Deberías reescribir el código que heredaste?

Probablemente no, y desde luego no en el primer mes. Una reescritura tira a la basura cada corrección de bug y cada caso límite que el sistema anterior aprendió en producción, y deja al negocio sin mejoras durante meses.

Después de 30 días tienes la evidencia para decidir. Reescribe una parte del sistema cuando:

• Los cambios en ella son lentos y riesgosos de forma constante, y puedes demostrarlo con ejemplos.
• Su tecnología bloquea algo que el negocio necesita a continuación.
• Puedes reemplazarla de forma gradual, un flujo a la vez, detrás de un switch.

Si decides ir por ese camino, migra recorrido por recorrido mientras el sistema anterior sigue funcionando. Escribí sobre migrar una plataforma en producción a un stack nuevo sin downtime, que es exactamente ese enfoque.

¿Qué deberías preguntarle al equipo anterior?

Si todavía puedes contactar al equipo saliente, una o dos horas con ellos valen más que una semana leyendo código. Pregunta:

• ¿Qué se rompe con más frecuencia y cómo lo arreglan?
• ¿Qué partes del código les da miedo tocar y por qué?
• ¿Qué quedó a medias: features, migraciones, refactorizaciones?
• ¿Qué jobs programados, scripts o tareas manuales mantienen el sistema funcionando?
• ¿Qué harían a continuación si se quedaran?

Registra las respuestas. La última pregunta es la que la gente responde con más honestidad cuando va de salida.