Cómo auditar el código heredado de una aplicación a medida antes de retomar el proyecto

Hay una llamada que recibimos más de lo que parece. Una empresa tiene una aplicación a medida que lleva años funcionando, le da dinero o le sostiene una operación interna, y de repente se queda sin quien la mantenga. El proveedor que la construyó cerró, el desarrollador estrella se marchó a otra cosa, o el contrato terminó hace tiempo y nadie tocó nada porque "iba bien". Ahora hace falta evolucionarla, corregir un fallo gordo o adaptarla a una normativa nueva, y al abrir el capó nadie sabe muy bien qué hay dentro.

La tentación, en ese momento, es ponerse a programar. Es lo que el cliente quiere oír: "tranquilo, lo arreglamos". Pero meter mano a un sistema que no entiendes es la forma más rápida de convertir un problema acotado en un agujero sin fondo. Antes de tocar una sola línea conviene parar y auditar lo que se ha heredado. No por burocracia, sino porque esa auditoría es la diferencia entre presupuestar con datos y presupuestar con esperanza.

Este artículo recoge cómo lo hacemos cuando nos llega un proyecto en estas condiciones, qué miramos y en qué orden, y cómo se traduce todo eso en una decisión sobre qué hacer con la aplicación.

Por qué auditar antes de tocar nada

Cuando heredas una aplicación a medida, heredas también todo lo que no se ve: decisiones de arquitectura tomadas hace seis años, dependencias que ya no recibe actualizaciones, parches sobre parches y, casi siempre, una distancia enorme entre lo que el sistema parece hacer y lo que hace de verdad.

Tocar sin entender tiene un coste concreto. Cambias algo en un módulo y se rompe otro que no sabías que estaba conectado. Actualizas una librería y la aplicación deja de arrancar. Corriges un bug y descubres que ese comportamiento "incorrecto" era el que sostenía un proceso de facturación. He visto equipos perder semanas deshaciendo cambios que parecían triviales porque nadie había mapeado las dependencias internas antes de empezar.

La auditoría sirve para tres cosas muy prácticas. La primera, saber si el proyecto es siquiera viable: hay casos en los que retomar cuesta más que rehacer, y es mejor descubrirlo en la semana uno que en el mes cuatro. La segunda, poder dar un presupuesto que se sostenga, con un margen de error razonable en lugar de un número inventado. Y la tercera, protegerse: si la aplicación maneja datos personales y arrastra un fallo de seguridad de 2019, quien la retome sin auditarla está asumiendo un riesgo que ni conoce.

Lo primero: acceso real, no acceso prometido

Antes de juzgar la calidad del código hay que poder verlo entero, y aquí es donde aparecen las primeras sorpresas.

El repositorio es el punto de partida. ¿Existe? ¿Está completo? Pregunta con frecuencia inquietante: muchas empresas creen tener el código y lo que tienen es lo que corre en producción, sin historial de versiones, sin ramas, sin saber si esa carpeta es realmente la última versión o una copia de hace año y medio. Si solo hay un ZIP en un correo antiguo, ya tienes el primer hallazgo.

Junto al repositorio van las credenciales y los accesos. Servidores, base de datos, panel de hosting, dominios, certificados, cuentas de los servicios externos que la aplicación usa (pasarela de pago, envío de correo, APIs de terceros). Es muy habitual que el conocimiento de "dónde está cada cosa" se fuera con la persona que se marchó. Conviene levantar un inventario de todo aquello a lo que se tiene acceso y, sobre todo, de aquello a lo que no. Esa segunda lista suele ser la cara.

Y una pregunta incómoda que toca hacer pronto: ¿de quién es el código? Quién figura como titular de los derechos, si hubo cesión por contrato, si quedó algún componente atado al proveedor anterior. Lo veremos más abajo con las licencias, pero el acceso técnico y la propiedad legal no siempre coinciden.

Qué revisar dentro del código

Con acceso garantizado, empieza el trabajo de fondo. No se trata de leer cada fichero, sino de tomar el pulso al estado real del sistema.

Documentación (o su ausencia)

Lo primero que se busca es un README decente, un diagrama de arquitectura, instrucciones de despliegue, algo. Casi nunca está. Lo normal es encontrar documentación desactualizada que describe una versión que ya no existe, lo cual es peor que no tener nada porque despista. Parte del trabajo de auditoría consiste, de hecho, en producir la documentación que debería haber existido: cómo se levanta el entorno, qué hace cada parte, cuáles son los puntos sensibles.

Dependencias y versiones obsoletas

Aquí es donde suelen estar los sustos. Toda aplicación a medida se apoya en librerías y frameworks de terceros, y esos componentes envejecen. Hay que listar todas las dependencias y comprobar su estado: cuáles están al día, cuáles llevan años sin actualizar y, lo más serio, cuáles han llegado a fin de vida (EOL) y ya no reciben parches de seguridad.

Una aplicación que corre sobre una versión de PHP, Node o un framework que dejó de mantenerse hace tiempo no es solo un problema técnico, es una puerta abierta. Y actualizar no siempre es trivial: a veces saltar dos versiones mayores de un framework implica reescribir la mitad de la lógica. Conviene saberlo antes de prometer una migración rápida.

Deuda técnica

La deuda técnica es todo eso que se hizo deprisa, mal o de forma provisional y que nunca se corrigió. Código duplicado, funciones de seiscientas líneas, lógica de negocio mezclada con la presentación, nombres que no significan nada, configuraciones a fuego dentro del código. No toda deuda es urgente, pero conviene medirla y, sobre todo, localizar dónde se concentra. Los puntos donde el código es más enrevesado suelen coincidir con los módulos que más cambian, y ahí es donde dolerá cada modificación futura.

Cobertura de tests

Pregunta directa: ¿hay tests? Si la respuesta es no —que es lo más frecuente en proyectos heredados—, cualquier cambio se hace a ciegas. Sin una red de pruebas, no hay forma de saber si lo que tocas rompe algo en otra parte hasta que un usuario te lo cuenta. La cobertura de tests, cuando existe, dice mucho de la cultura del equipo anterior y de cuánto margen hay para trabajar con seguridad. Su ausencia no descarta retomar el proyecto, pero sí encarece cada intervención y debe reflejarse en el presupuesto.

Seguridad y cumplimiento, sin atajos

Una aplicación heredada que gestiona datos de personas es una responsabilidad legal desde el minuto en que la retomas. Por eso la parte de seguridad no es un extra, es un bloque propio de la auditoría.

Se revisan las vulnerabilidades conocidas en las dependencias, la forma en que se gestionan las contraseñas y los accesos, si hay datos sensibles guardados sin cifrar, si las comunicaciones van protegidas, si existen credenciales escritas directamente en el código (las hay, casi siempre las hay). Un escaneo de seguridad básico sobre el repositorio y la infraestructura suele aflorar lo más urgente en pocas horas.

En España, además, está el RGPD. Si la aplicación trata datos personales hay que comprobar qué se recoge, dónde se almacena, durante cuánto tiempo, quién accede y si hay registro de todo ello. Una app heredada rara vez cumple del todo, y heredarla implica heredar también esa obligación. Detectar el desfase pronto evita sustos mayores con la Agencia Española de Protección de Datos más adelante.

Infraestructura, backups y licencias

El código no vive solo. Hay que entender dónde corre la aplicación, sobre qué servidores, con qué configuración, y si esa infraestructura está documentada o es otra caja negra.

El punto de los backups merece detenerse. ¿Existen copias de seguridad? ¿Cada cuánto se hacen? ¿Alguien ha comprobado alguna vez que se pueden restaurar? Un backup que nadie ha probado es un backup que no existe hasta que se demuestre lo contrario. Antes de tocar producción, lo primero es asegurar que hay una copia recuperable; suena obvio y es justo lo que más veces falta.

Y las licencias. Una aplicación a medida es a menudo un mosaico de componentes de terceros, y cada uno tiene su licencia. La mayoría son permisivas, pero de vez en cuando aparece algo con una licencia restrictiva que obliga a publicar el código o que prohíbe ciertos usos comerciales. Conviene revisarlo, porque heredar una aplicación con un componente mal licenciado puede salir caro si el proyecto crece o se comercializa.

Cómo medir el estado: métricas y mapa de riesgos

Todo lo anterior solo sirve si se traduce en algo que el cliente pueda entender y sobre lo que pueda decidir. Por eso cerramos la auditoría con dos entregables.

El primero son unas métricas claras del estado del código: número de dependencias obsoletas y cuántas en EOL, cobertura de tests si la hay, puntos calientes de complejidad, vulnerabilidades detectadas por gravedad, porcentaje de la aplicación que está documentada. Cifras, no impresiones. Permiten comparar y, más adelante, medir el progreso.

El segundo es un mapa de riesgos: cada problema encontrado, clasificado por probabilidad de que estalle y por impacto si lo hace. Una credencial en texto plano y una dependencia EOL en la pasarela de pago van arriba del todo. Un nombre de variable feo, abajo. Ese mapa es el que ordena el trabajo: dice qué se ataca primero, qué puede esperar y qué hay que vigilar aunque no se toque.

Mantener, refactorizar o reescribir

Con la foto completa llega la decisión de fondo, y rara vez es blanca o negra.

Mantener tiene sentido cuando el código está razonablemente sano, cumple su función y los cambios que se piden son acotados. Se estabiliza, se actualiza lo crítico, se documenta y se sigue. Es la opción más barata y, cuando es viable, la más sensata.

Refactorizar es el camino intermedio y el más habitual en proyectos rescatables. La aplicación funciona pero arrastra deuda, y se va mejorando por partes sin parar el negocio: se añaden tests donde más se va a tocar, se actualizan dependencias por fases, se reordenan los módulos más enrevesados. Avanza más despacio pero sin grandes saltos al vacío.

Reescribir es la opción más cara y la más arriesgada, y casi nunca es la primera respuesta correcta. Tiene sentido cuando la tecnología base está muerta, cuando la deuda es tan grande que cada cambio cuesta más que rehacerlo, o cuando el sistema no puede crecer hacia donde el negocio necesita. Reescribir desde cero suele subestimarse: esa aplicación "fea" lleva dentro años de reglas de negocio que nadie recuerda y que reaparecen, una a una, en cuanto la nueva versión sale a producción. Si se decide, mejor por fases y conviviendo con lo viejo, no de golpe.

La auditoría es justo lo que permite tomar esta decisión con criterio en lugar de por intuición o por lo que más conviene facturar.

Cómo presupuestar la continuidad

Un proyecto heredado bien auditado se puede presupuestar de verdad. Sin auditar, cualquier cifra es un brindis al sol.

Lo primero es separar dos partidas que suelen mezclarse: estabilizar y evolucionar. Estabilizar es dejar la aplicación en un estado seguro y mantenible —tapar agujeros de seguridad, asegurar backups, actualizar lo que está en EOL, documentar lo mínimo—. Evolucionar es construir lo nuevo que el cliente quería desde el principio. Conviene presupuestarlas por separado, porque mezclarlas oculta cuánto cuesta simplemente poner el sistema en condiciones.

A partir de ahí, el presupuesto sale del mapa de riesgos y de la decisión sobre mantener, refactorizar o reescribir. Recomendamos arrancar siempre con una fase corta y acotada —la propia auditoría más las primeras estabilizaciones— para que el cliente vea resultados rápido y para validar las estimaciones con código real antes de comprometerse con lo grande. Es más honesto y, a la larga, más barato para todos.

Si tienes una aplicación a medida parada y quieres saber en qué estado está antes de invertir un euro más, pide una auditoría de tu aplicación y te diremos con datos qué hay dentro y qué tiene sentido hacer.

El primer mes con un proyecto heredado

Las primeras semanas marcan el tono de todo lo que viene después. El orden que seguimos es bastante constante: garantizar acceso completo y comprobar que existe un backup recuperable, levantar el entorno en local para confirmar que el código que tenemos es el que corre de verdad, y a partir de ahí ejecutar la auditoría que hemos descrito.

El objetivo de ese primer mes no es arreglar la aplicación, sino entenderla y dejar claro el terreno. Al final hay tres cosas sobre la mesa: un informe del estado con métricas y mapa de riesgos, una recomendación argumentada sobre mantener, refactorizar o reescribir, y un presupuesto por fases que separa estabilizar de evolucionar. Con eso, retomar el proyecto deja de ser un salto de fe y pasa a ser una decisión informada. Que es, al final, lo único que permite rescatar un proyecto en lugar de hundirse con él.