.jpg)
Cuando una empresa contrata a una agencia para desarrollar un proyecto de software, la entrega suele incluir un repositorio, una aplicación desplegada y un conjunto de promesas sobre su funcionamiento. Pero la realidad, muchas veces, es muy distinta: la documentación está incompleta, el código acumula deudas técnicas y los riesgos operativos se ocultan bajo una capa de urgencia. Si te ha tocado tomar las riendas de un desarrollo heredado, sabes que no basta con ejecutar un checklist superficial. Se necesita un proceso metódico, estructurado en varios días, que permita entender realmente lo que se tiene antes de cambiarlo.
El primer día, la tentación de empezar a limpiar código es casi irresistible. Sin embargo, la prioridad es otra: construir un modelo mental del sistema sin modificar nada. Leer el repositorio, los históricos de despliegue, el rastreador de incidencias y cualquier comunicación previa permite identificar qué partes son críticas. Una función aparentemente obsoleta puede ser el pilar de una funcionalidad oculta. También conviene verificar si existe observabilidad: ¿hay logs accesibles? ¿alertas de disponibilidad? ¿alguien recibe notificaciones si el sistema cae a las 2 de la madrugada? Sorprendentemente, muchos proyectos de agencia carecen de esta capa, lo que supone un riesgo de ciberseguridad y operativo que debe estar en lo más alto de la evaluación.
El segundo día se dedica a poner en marcha el entorno local desde cero. Seguir al pie de la letra el README y anotar cada paso que falta o está mal documentado revela mucho sobre la calidad general del código. Si para arrancar hacen falta seis variables de entorno no especificadas, una versión antigua de PostgreSQL y migraciones que fallan, es probable que el resto del sistema arrastre problemas similares. Este ejercicio produce una lista de obstáculos que servirá como base del informe de asunción. En Q2BSTUDIO, cuando realizamos auditorías técnicas sobre aplicaciones a medida, este paso es fundamental para entender la salud del proyecto.
Al tercer día se traza la arquitectura real del sistema, ignorando los diagramas teóricos que entregó la agencia. Hay que seguir el flujo de datos desde que una petición entra hasta que se escribe en la base de datos: trazar rutas críticas como la creación de un usuario, un pedido o la recepción de un webhook. Es el momento de abrir el archivo de dependencias y sorprenderse con versiones obsoletas, paquetes abandonados o tres librerías diferentes para formatear fechas. También conviene mapear todas las integraciones externas: llamadas a APIs de terceros, colas de mensajes, trabajos programados. Una arquitectura mal documentada es una fuente constante de errores difíciles de depurar, especialmente cuando se utilizan servicios cloud AWS y Azure que requieren configuraciones de red específicas.
El cuarto día está reservado para la seguridad y las pruebas. Antes de pensar en rendimiento o en código limpio, hay que buscar vulnerabilidades reales: secretos en el repositorio (incluso en el historial de git), falta de autenticación consistente en rutas protegidas, inyecciones SQL en consultas sin ORM, ausencia de limitación de tasa en endpoints sensibles o configuraciones CORS demasiado permisivas. Una auditoría de dependencias con npm audit suele revelar CVEs críticas que exigen atención inmediata. En paralelo, se ejecuta la suite de tests (si existe) y se analiza su calidad. Muchas veces los tests solo cubren caminos felices y silencian errores. Antes de añadir nuevas pruebas, conviene escribir pruebas de caracterización que capturen el comportamiento actual del sistema, estableciendo una red de seguridad. En este punto, la integración de inteligencia artificial o agentes IA puede automatizar parte del análisis de logs y detectar anomalías, pero lo esencial es tener una línea base.
El quinto día se consolida el informe de asunción. Este documento no es para desarrolladores, sino para los responsables del negocio. Debe describir la arquitectura real, qué funciona y qué no localmente, los riesgos de ciberseguridad priorizados por severidad, las diferencias entre lo prometido y lo implementado, y una ruta de estabilización. Es crucial distinguir entre deuda estética (nombres inconsistentes, funciones largas pero correctas) y deuda real (errores sin captura, falta de reintentos en llamadas externas, consultas N+1 que colapsarán con más carga). La recomendación final casi nunca es reescribir desde cero: se apuesta por estabilizar, parchear vulnerabilidades y reemplazar módulos problemáticos uno a uno, siguiendo el patrón de la higuera estranguladora. Esta estrategia evita perder el conocimiento implícito que contiene el código antiguo, acumulado tras años de incidentes reales.
Tomar el control de un código de agencia en cinco días no es un lujo, es una necesidad para cualquier empresa que quiera tener visibilidad real de su activo tecnológico. En Q2BSTUDIO ofrecemos servicios de inteligencia de negocio y Power BI para monitorizar el rendimiento de las aplicaciones, así como servicios cloud AWS y Azure para migrar a infraestructuras más robustas. Si tu proyecto heredado necesita un diagnóstico profundo o una estrategia de mejora continua, nuestro equipo de desarrollo de aplicaciones a medida puede ayudarte a transformar ese caos en un sistema fiable. También contamos con servicios de ciberseguridad y pentesting para detectar vulnerabilidades antes de que lo hagan los atacantes. La tecnología debe servir al negocio, no secuestrarlo.
