Auditoría de software, código y deuda técnicaConocer el programa antes de invertir en su siguiente etapa.

LA PREGUNTA

No auditamos el código «en general»: primero definimos qué necesitas decidir

Una empresa puede querer ampliar una función, cambiar de proveedor, comprender errores recurrentes, valorar una migración o comprobar una entrega recibida. Cada pregunta pide revisar módulos, recorridos y dependencias diferentes. Esta especialidad forma parte de nuestras auditorías tecnológicas, cada una con un alcance propio.

Un repositorio grande puede contener años de trabajo. Leerlo entero sin un objetivo no garantiza una respuesta útil; acordamos alcance y muestras suficientes para fundamentar la decisión.

CONTEXTO

Antes de juzgar el código necesitamos saber qué sistema estamos mirando

Un repositorio no explica por sí solo qué versión está en producción, qué otros componentes participan ni cómo se configura el entorno. Identificamos, según el alcance, código, dependencias, migraciones, documentación, datos, integraciones y forma de publicación.

Una aplicación puede parecer incompleta porque parte de la lógica reside en otro servicio. También puede parecer ordenada mientras depende de tareas manuales que sólo conoce una persona. Situar el código en su contexto evita ambos errores.

EJECUCIÓN

Poder ejecutar el proyecto forma parte del conocimiento que debe conservarse

Comprobamos qué hace falta para poner en marcha las partes relevantes: versiones, configuración, datos, servicios externos y pasos manuales. Necesitar preparación no convierte un proyecto en malo; la limitación aparece cuando el procedimiento depende de información inaccesible o cuentas personales.

Indicamos qué pudimos reproducir, qué condiciones faltan y cuánto condiciona eso el diagnóstico.

COMPORTAMIENTO

El código se interpreta mejor cuando sabemos qué intenta hacer

Relacionamos los componentes con recorridos y reglas reales. Cuando es viable ejecutamos situaciones representativas y observamos qué partes intervienen. Una función larga no es automáticamente crítica, igual que una clase pequeña no demuestra calidad.

Una regla empresarial puede ser compleja por naturaleza. El problema aparece si está duplicada, dispersa o si cambiarla altera funciones aparentemente independientes. La pregunta es qué dificultad técnica afecta a ese comportamiento concreto.

ESTRUCTURA

Localizar dónde termina una responsabilidad y empieza otra

Revisamos cómo se reparten las responsabilidades en las zonas incluidas. Si una pieza conoce la interfaz, los datos, las reglas y varias integraciones, cualquier modificación puede tener efectos difíciles de anticipar.

Buscamos lógica repetida, reglas repartidas, efectos secundarios poco visibles y módulos que sólo pueden cambiarse juntos. El tamaño de un archivo o una métrica automática pueden orientar la revisión, pero no sustituyen la explicación del efecto real.

DEPENDENCIAS

Una dependencia antigua no es automáticamente deuda crítica

Examinamos la función, versión, mantenimiento y compatibilidad de librerías, frameworks y servicios relevantes. Preguntamos si una dependencia bloquea actualizaciones, presenta un problema conocido, impide la función prevista o compromete otra parte del sistema.

Una tecnología estable puede requerir menos atención que una dependencia reciente que genera incompatibilidades. Si recomendamos actualizar, explicamos qué habría que comprobar antes.

PRUEBAS

No contamos tests: analizamos qué comportamiento protegen

Una carpeta con muchas pruebas puede dejar sin proteger una regla crítica. A la inversa, un sistema con pocas pruebas automáticas puede tener comprobaciones manuales conocidas. Describimos qué cambios serían difíciles de validar y por qué.

Si el diagnóstico revela comportamientos sin protección, la guía de testing de software explica cómo priorizar comprobaciones alrededor de los riesgos reales, sin usar el número de tests como objetivo.

Una prueba también puede convertirse en deuda

Si depende de detalles internos y se rompe al reorganizar código sin alterar el comportamiento, revisamos si sigue aportando confianza o sólo coste de mantenimiento.

DATOS

Cambiar código también puede significar cambiar datos que ya existen

Revisamos cómo se representa la información relevante y cómo evolucionó su estructura. Campos ambiguos, migraciones acumuladas, datos duplicados o reglas escondidas en el código pueden condicionar una ampliación.

Una versión nueva debe funcionar con los datos reales, no sólo con una base vacía. Identificamos las migraciones o compatibilidades que habría que validar antes de intervenir.

SISTEMAS EXTERNOS

Una dependencia externa puede limitar la evolución

APIs, pasarelas, ERP o proveedores de identidad participan en la arquitectura real. Examinamos los recorridos afectados, los datos compartidos y qué ocurre cuando el otro sistema falla o cambia su interfaz.

Si el siguiente paso consiste en implementar una conexión o corregirla, la intervención corresponde a integración de sistemas y APIs.

FALLOS

Un error útil permite saber qué ocurrió y dónde buscar

Observamos cómo se propagan los errores en las zonas revisadas. Un fallo absorbido puede hacer que una operación parezca completada a medias; uno expuesto sin filtro puede mostrar información interna innecesaria.

Nos interesa qué estado deja la operación, si puede repetirse con seguridad, si queda rastro suficiente y qué información recibe quien debe investigar. Si la necesidad principal son alertas y observación continuada, corresponde a monitorización operativa.

CONFIGURACIÓN

Distinguir el software de aquello que cambia entre entornos

Dominios, rutas, credenciales y servicios externos pueden estar mezclados con el código. Revisamos cómo se suministra la configuración y qué información falta para reproducir el entorno. No presupone que todo proyecto deba tener la misma estructura de desarrollo y producción.

ENTREGA

Cómo se publica una versión también condiciona la evolución

Revisamos el camino que sigue un cambio hasta ponerse en uso: preparación, dependencias, migraciones, pasos manuales y comprobaciones posteriores. Una publicación frágil puede hacer costosa una mejora pequeña.

El diagnóstico identifica ese riesgo. Diseñar pipelines o procedimientos nuevos pertenece a CI/CD y automatización de despliegues.

CONOCIMIENTO

La documentación útil permite entender decisiones y operar el sistema

Comprobamos si existe información suficiente para localizar responsabilidades, preparar el entorno y comprender decisiones que todavía condicionan el trabajo. Documentar cada línea no es el objetivo; tampoco puede sustituirse todo por conocimiento informal de una persona.

Señalamos qué ausencia impide una tarea concreta y qué información convendría recuperar.

DEUDA TÉCNICA

Una limitación se vuelve relevante cuando encarece cambios necesarios

Una decisión anterior puede haber sido razonable. La deuda técnica aparece cuando la estructura actual aumenta de forma apreciable el coste, riesgo o dificultad de cambios que la empresa necesita realizar.

La describimos mediante una relación verificable: cambio previsto → obstáculo observado → consecuencia → alternativa. Un bug, una vulnerabilidad y una función pendiente son problemas distintos; no los llamamos deuda técnica por comodidad.

La auditoría diagnostica el estado actual. Para entender cómo intentamos evitar que esas dificultades se acumulen durante el desarrollo, consulta nuestros criterios de calidad y mantenibilidad del software.

PRIORIDAD

No toda deuda debe pagarse ahora

Una limitación aislada y conocida puede mantenerse si corregirla cuesta más que convivir con ella. Priorizamos según el cambio previsto, la probabilidad de encontrar el obstáculo, su impacto y el esfuerzo de intervención.

COMPLEJIDAD

Distinguir la complejidad del negocio de la que añade la implementación

Un proceso con tarifas, estados y excepciones puede ser difícil aunque el código esté bien organizado. La auditoría no promete eliminar reglas que el negocio realmente necesita.

Identifica la complejidad accidental: duplicación, dependencias ocultas, conversiones manuales y decisiones que podrían representarse de forma más clara.

REESCRIBIR O EVOLUCIONAR

Reescribir todo exige una justificación propia

Una reescritura puede parecer más limpia que comprender un sistema antiguo, pero también puede perder reglas implícitas, datos y recorridos que hoy funcionan. Antes de recomendarla contrastamos alcance, coste, riesgos de migración y alternativas parciales.

Conservar, corregir o sustituir un componente son opciones distintas. La antigüedad del framework no decide por sí sola el destino de la aplicación.

REFACTORIZAR

Una refactorización necesita objetivo y forma de validación

Refactorizar cambia la estructura interna sin buscar un comportamiento nuevo. Tiene sentido cuando facilita un cambio previsto o reduce un riesgo demostrado. Explicamos qué zona se tocaría, qué comportamiento debe mantenerse y cómo comprobarlo.

Una limpieza estética sin relación con un problema real no obtiene prioridad automática.

LÍMITES

Decir qué no hemos podido verificar es parte del informe

Puede faltar un entorno ejecutable, una cuenta, datos representativos o documentación de un proveedor. No presentamos esas zonas como comprobadas. Distinguimos lo observado, lo inferido y lo que queda pendiente.

Una herramienta automática puede localizar versiones o señalar zonas interesantes; su puntuación no sustituye evidencia de comportamiento e impacto. La incertidumbre se convierte en una tarea concreta de investigación, no en una certeza ficticia.

CAMBIO DE EQUIPO

Un nuevo proveedor necesita más que un repositorio

Revisamos, si ésa es la pregunta, acceso al código, preparación del entorno, dependencias, datos, materiales de entrega y conocimiento que sólo posee el equipo anterior. El informe permite planificar la transición sin atribuir culpas ni obligar al cliente a contratarnos después.

NUEVA ETAPA

Antes de ampliar, identificar qué puede recibir el cambio

Si una empresa quiere añadir funciones importantes, la revisión localiza zonas afectadas, restricciones y comportamiento que debe preservarse. No toda ampliación necesita una auditoría previa; ésta aporta valor cuando la incertidumbre haría arriesgado empezar a construir directamente.

REVISIÓN DE ENTREGA

Comprobar una entrega exige compararla con lo acordado

Cuando revisamos software de otro proveedor solicitamos alcance, requisitos, versión recibida y condiciones de entrega. Diferenciamos incumplimiento funcional, defecto técnico, limitación conocida, mejora opcional y preferencia de implementación.