Una auditoría de código heredado que merece la pena

Una auditoría de código heredado solo merece la pena si otro equipo competente puede actuar con ella sin comprar un segundo proyecto de descubrimiento. Debe explicar qué existe, qué sigue ejecutándose, qué procesos de negocio pueden fallar y cuánto costará cada unidad razonable de cambio. Si termina en diagramas, puntuaciones de calidad y una recomendación de modernizar, ha comprado un documento de ventas.

He revisado auditorías que parecían caras porque eran largas. Las útiles solían costar más trabajo y resultar más fáciles de leer. Cada afirmación llevaba al código, a pruebas de ejecución, a una entrevista o a una hipótesis explícita. Cada fase tenía límite, prueba de aceptación, dependencias y precio. Esa trazabilidad marca la diferencia.

La auditoría debe fijar los límites antes de juzgar

Una auditoría creíble empieza diciendo exactamente qué inspeccionó y qué dejó fuera. Los sistemas antiguos rara vez caben en un repositorio. Una aplicación COBOL puede depender de JCL, planificadores, copybooks, objetos DB2, transferencias y un Excel de finanzas. Una aplicación de escritorio puede escribir en una base compartida mientras un script nocturno corrige registros que la interfaz no permite arreglar. Omitir esos bordes invalida conclusiones posteriores.

El registro de alcance debe identificar repositorios, ramas, versiones desplegadas, archivos de compilación, esquemas, trabajos, interfaces, configuración, informes y procedimientos operativos. Para cada elemento debe constar la fuente de prueba y la versión o fecha observada. Un nombre de repositorio sin commit no demuestra qué se analizó; un esquema de desarrollo no demuestra qué usa producción.

También hace falta una lista de exclusiones. Quizá no pueda inspeccionarse un paquete, los registros solo guarden siete días o el compilador antiguo no funcione. No son notas menores: limitan las afirmaciones. Cada exclusión debe explicar su consecuencia, por ejemplo: "La accesibilidad del batch sigue sin conocerse porque no había historial del planificador."

Pida una tabla con activo, prueba inspeccionada, confianza y carencia. La confianza refleja calidad de evidencia, no intuición. Código, salida de compilación y trazas de producción valen más que una entrevista sola. Sin límites y carencias, el análisis no se reproduce ni justifica su precio.

El mapa de módulos debe mostrar conducta, datos y responsables

Un mapa útil es un inventario unido a pruebas de dependencia, no una página de cajas de colores. Al seleccionar un módulo, un ingeniero debe saber quién lo llama, qué llama, qué datos lee o cambia y qué proceso depende de él. Grafo, tabla o ambos sirven si hay identificadores estables y aristas rastreables.

Cada nodo debe incluir ruta, lenguaje, desplegable o trabajo, puntos de entrada, datos persistentes, interfaces externas, disparador u horario y responsable. Cada arista debe indicar su prueba. Resolución estática, imports, SQL, configuración del planificador, metadatos y tráfico observado son evidencias distintas. Mezclarlas oculta incertidumbre.

Las dependencias heredadas son desordenadas. Llamadas dinámicas, nombres generados, reflexión, tablas compartidas, archivos temporales y registros de control engañan a un analizador simple. El informe debe conservar aristas no resueltas. "Destino calculado en ejecución" resulta útil; un diagrama limpio que omite la llamada resulta peligroso. Los ciclos deben seguir visibles porque suelen decidir el orden de extracción.

El mapa necesita una capa de negocio. "ARUPD07 llama a DATECNV" ayuda al ingeniero. "El cierre de aplicación de cobros depende de ARUPD07 y de la importación bancaria" ayuda a decidir. Ambas vistas deben vivir en el mismo modelo con pruebas que las unan. Si después hace falta un taller para reconstruir esa relación, el entregable está incompleto.

Exija los datos, no solo diagramas. Basta un archivo de aristas:

source_id,target_id,edge_type,evidence,confidence,business_process
ARUPD07,DATECNV,static_call,src/ar/ARUPD07.cbl:418,high,cash_application
NIGHTLY_AR,ARUPD07,schedule,ops/sched/nightly.jcl:77,high,cash_application
ARUPD07,BANK_RATE,dynamic_call,production_trace:sample_042,medium,cash_application

El equipo puede comparar, consultar y cargar ese archivo en cualquier herramienta. Una captura encerrada en un PDF no sirve para planificar ni verificar después.

El código muerto es una afirmación medida, no un porcentaje

La auditoría debe separar código inalcanzable, no observado, latente y estructuras sin uso porque conducen a decisiones distintas. Los equipos mezclan categorías y borran algo que solo corre al cierre anual. El análisis estático puede mostrar que ninguna entrada conocida alcanza un procedimiento. La observación solo muestra que no se ejecutó durante una ventana. No equivalen.

El registro debe identificar unidad, método, ventana, ciclos cubiertos, pruebas contrarias, confianza y acción. Contar líneas es débil. Diez mil líneas generadas pueden regenerarse con seguridad y una excepción fiscal de veinte líneas tener gran riesgo. Mida unidad lógica y conducta antes de resumir en porcentaje.

Use varias pruebas: referencias de compilación, accesibilidad estática, historial de trabajos, trazas, acceso a datos, feature flags y operadores. Ninguna basta. El historial omite recuperaciones manuales, las trazas rutas trimestrales y las entrevistas conservan folklore obsoleto. La coincidencia entre fuentes eleva la confianza; sus contradicciones van al informe.

Un registro defendible diría: "CLAIMS_REPRINT no tiene llamadores estáticos, entrada programada ni ejecución en dos ciclos normales. Operaciones dice que soporte lo inicia tras fallos de impresora. Clasificación: ruta de recuperación latente, no muerta. Acción: conservar hasta que el reemplazo incluya la recuperación." Es más útil que un panel con un 18 % de código muerto.

Exija numerador y denominador. ¿"Sin uso" significa líneas, funciones, programas, tablas, pantallas o pasos? ¿Se excluyeron comentarios y fuentes generadas? ¿Se cubrieron compilación condicional y llamadas dinámicas? Sin respuestas, use el porcentaje como pista, no como base de alcance o ahorro.

Los riesgos deben apuntar a procesos y modos de fallo

Una lista ordenada sirve si cada elemento conecta una condición técnica con un evento de negocio, un fallo y un impacto observable. "Alto acoplamiento" aún no es un riesgo. "El trabajo de facturación y el servicio de crédito actualizan la misma tabla con reglas distintas; un fallo parcial puede liberar pedidos contra un saldo obsoleto" sí permite decidir.

Cada riesgo debe incluir proceso, evento, causa, conducta del fallo, detección, control existente, alcance, prueba y remedio. La clasificación debe explicar probabilidad e impacto. Los decimales no vuelven objetivas las opiniones; escalas simples y definidas suelen funcionar mejor.

No ponga mantenibilidad por encima de producción porque un escáner la cuente. Un procedimiento de 4.000 líneas puede ser feo pero estable. Una conciliación limpia de 200 puede perder registros al recibir dos veces un archivo. Clasifique el segundo caso por encima si hay pruebas. Exposición, frecuencia de cambio, recuperación y demora de detección pesan más que la estética.

Los riesgos necesitan un propietario capaz de resolver o aceptar la exposición, no necesariamente el desarrollador. Si el proceso no tiene dueño, registre esa carencia de gobierno en lugar de asignarla a "TI".

Uso una prueba directa: ¿reconoce el fallo quien ejecuta el proceso? Si cuentas por cobrar, almacén o cumplimiento no relacionan el registro con un evento real, probablemente se ordenaron olores de código y no riesgos operativos.

Las pruebas de ejecución deben cubrir el calendario importante

Una traza solo sirve si su ventana encaja con el calendario de negocio. Treinta días normales pueden cubrir miles de peticiones y omitir cierre trimestral, renovación anual, precio estacional o recuperación infrecuente. La auditoría debe indicar ciclos cubiertos y ausentes.

Prepare un calendario diario, semanal, de fin de mes, trimestral, anual, por evento y de recuperación. Asigne las ejecuciones. Así el volumen web no tapa un batch raro. Use configuración, procedimientos, transacciones y entrevistas, no solo memoria.

Privacidad y límites operativos forman parte del método. Quizá se usen formas de petición, hashes, recuentos, muestras o logs redactados. El informe debe explicar el tratamiento de campos sensibles y la fidelidad perdida. Nunca debe copiar credenciales o datos personales para probar que hubo trazas.

El entregable debe mostrar identificadores, horas, entradas, estado, componentes, tablas o archivos y proceso asociado. Los agregados deben enlazar con observaciones. Sin esa cadena, cualquiera puede llamar a una ruta "activa" o "sin uso" sin demostrarlo.

La falta de telemetría no convierte el código en muerto. Cambia la recomendación: instrumentar, observar más o reproducir de forma controlada antes de borrar. La incertidumbre es normal; ocultarla no.

El plan por fases necesita límites, pruebas y precios

Una fase solo se compra cuando alcance, dependencias, aceptación y precio son explícitos. "Base, transformación, optimización" no explica qué cambiará tras la factura. Una buena fase nombra la porción de negocio o costura técnica, activos modificados, interfaces estables y prueba exigida.

Cada fase debe declarar cinco cosas:

1. Módulos, datos, interfaces y proceso incluidos.
2. Condiciones y decisiones del cliente.
3. Entregables y entorno de ejecución.
4. Pruebas de aceptación, incluida paridad y operación.
5. Precio fijo o rango acotado con hipótesis.

Los precios sin hipótesis son cebo. Estas pueden cubrir herramientas, tráfico, esquemas, licencias o aceptación del cliente. Cada una debe llevar a un mecanismo de cambio valorado. Si falta una definición de interfaz, el informe debe decir cómo cambia alcance o precio.

La secuencia necesita argumento. Un módulo pequeño parece seguro, pero puede demostrar solo conversión de sintaxis. Una mejor primera fase cruza una costura representativa y prueba datos, build, despliegue y paridad con exposición limitada. La auditoría debe explicar qué incertidumbre reduce.

Incluya alternativas si las pruebas admiten varias rutas. Puede extraerse precios primero o estabilizar el contrato de base compartida. Muestre coste, dependencia y riesgo. Una única ruta puede disfrazar la preferencia del proveedor de necesidad técnica.

Las estimaciones deben reconstruirse desde las pruebas

Una estimación fiable deja ver cómo el alcance se convierte en precio. No necesita mostrar salarios o margen, pero sí unidades, complejidad, exclusiones, contingencias e hipótesis. Sin eso, el número invita a negociar y no permite planificar.

El modelo debe conectarse a los registros. Si una fase incluye doce programas, tres trabajos, dos interfaces y una tabla, debe citar sus identificadores. Los ajustes deben nombrar la causa: despacho dinámico, build ausente, formato no documentado, conversión o entorno indisponible. "Multiplicador de complejidad heredada" no basta.

Un rango es razonable si se explica cómo cerrarlo. Si el mínimo supone un build reproducible y el máximo reconstruirlo, una prueba de un día puede producir un precio firme. Un rango amplio sin regla transfiere el riesgo al comprador.

Pida un registro inspeccionable:

Phase: cash application slice
Scope IDs: NIGHTLY_AR, ARUPD07, DATECNV, BANK_RATE
Base work: behavior capture, target implementation, data adapter, deployment
Risk allowances: dynamic call resolution; incomplete printer-recovery trace
Customer inputs: redacted traffic set; operations reviewer
Acceptance: replay parity; close totals match; recovery procedure demonstrated
Price: [amount or bounded range]
Range closes when: build and recovery-path tests complete

El método puede variar, pero no la cadena entre activo, trabajo y precio. Si es secreta, no sabrá si la cifra refleja su sistema o un objetivo comercial.

Una auditoría real deja pruebas que su equipo puede cuestionar

El paquete final debe traer registros editables y exportaciones legibles por máquina. Sus ingenieros deben filtrar módulos latentes, rastrear un riesgo hasta tablas o saber qué fase posee una interfaz. Si el auditor controla el único modelo útil, usted ha alquilado el entendimiento.

Exija identificadores de evidencia. Una arista cita código o traza; un riesgo, aristas, incidentes y entrevistas; una fase, riesgos y activos. Los ingenieros pueden discutir una prueba concreta y no una conclusión del consultor.

Incluya notas de reproducción: herramientas, versiones, comandos, ramas, commits, ventanas, filtros, límites y correcciones manuales. El objetivo es distinguir evidencia generada de juicio humano y hacer ambos inspeccionables.

En la revisión, elija una ruta de ingresos, un batch, un módulo supuestamente muerto y una fase cara. Siga cada uno hacia atrás. Si la pista se rompe, registre el artefacto ausente antes de aceptar. Dice más que otra presentación.

El contrato debe transferir registros, esquemas, diagramas, scripts específicos y exportaciones útiles de entornos propietarios. Las licencias pueden limitar una herramienta, pero su modelo del sistema no debe desaparecer al caducar el acceso.

Los documentos de ventas se revelan antes del discurso final

Un documento comercial parte de un destino decidido y reúne pruebas para justificarlo. Una auditoría real deja que la evidencia cambie la recomendación, incluso para conservar parte del sistema. La propuesta y la primera revisión suelen delatarla.

Vigile estas señales:

• Los entregables prometen hallazgos sin definir campos o fuentes.
• El bajo precio se recuperará con una implementación supuesta.
• Los riesgos salen de un escáner genérico sin proceso de negocio.
• La hoja de ruta usa etapas amplias sin pruebas ni precios.
• El proveedor muestra el modelo pero no entrega los registros.

Rechace la precisión teatral. Una madurez de 2,7, un mapa rojo o un porcentaje exacto puede ocultar pesos arbitrarios. Pregunte qué decisión cambia con el valor. Si ninguna, decora la venta.

Independencia no equivale a neutralidad. Una empresa de ejecución puede auditar bien si separa prueba y recomendación, valora alternativas y transfiere artefactos. Una consultora sin entrega puede escribir vaguedades. Juzgue el trabajo y los incentivos.

Antes de firmar, ponga en el contrato registros, campos, formatos, enlaces, revisión y plazo de corrección. No acepte "informe completo" como entregable. Es un adjetivo; un registro con columnas definidas se inspecciona.

La auditoría debe permitir la primera decisión de entrega

Termina cuando la dirección puede elegir una primera fase acotada, entender el riesgo que reduce, ver sistemas y personas afectados y aprobar un precio ligado a pruebas. Un informe grueso que acaba en "más descubrimiento" no llega. Cada incógnita necesita dueño, método de resolución y decisión afectada.

El registro final debe incluir fase elegida, alternativas, referencias, hipótesis abiertas, pruebas, precio y condiciones de parada. Un build irreproducible, tráfico que contradiga el mapa o una interfaz controlada por un tercero pueden detener el trabajo. Nombrarlos evita mantener una estimación tras cambiar sus premisas.

Si se busca una reescritura, la paridad pertenece a la decisión. CodeHero lee todo el código y verifica la conducta preservada contra tráfico grabado de producción. Exija a cualquier proveedor qué conducta compara, qué tráfico la representa, cómo clasifica diferencias y quién las acepta. "Funcionalmente equivalente" sin arnés y arbitraje es otro adjetivo.

Pague por una auditoría si convierte incertidumbre en decisiones rastreables. Rechácela si la convierte en diapositivas. Entregue los artefactos a un ingeniero ajeno a los talleres y pídale alcance, evidencia, riesgo, prueba y precio de la fase uno. Si puede encontrarlos y conectarlos, la auditoría cumplió.