El conocimiento del sistema antiguo tras la reescritura

Las personas que entienden un sistema antiguo no son una molestia temporal en el camino hacia un código más limpio. Forman parte del modelo operativo actual del sistema. Una reescritura que ignore lo que saben puede reproducir todas las pantallas visibles y aun así fallar ante el primer reembolso inusual, ajuste de cierre trimestral o reinicio de un proceso por lotes.

El objetivo útil no es «descargar» el cerebro de alguien antes de que se jubile. Hay que convertir las afirmaciones sobre el comportamiento en pruebas que otra persona pueda examinar: ejemplos, tests, registros de decisiones, procedimientos operativos e incertidumbres identificadas. Este trabajo también da a los expertos una función creíble después del cambio. Hay que tratarlos como testigos y revisores, no como obstáculos ni como documentos humanos de especificaciones.

El sistema antiguo también incluye a su gente

El conocimiento de un sistema antiguo vive en varios lugares a la vez. Una parte está en el código fuente y en las definiciones de tareas. Otra aparece en los datos de producción, los manuales operativos, el historial de incidencias y las hojas de cálculo de conciliación. El resto vive en quienes saben que el estado de cliente 7 significa algo distinto antes del cierre de mes, o que un lote fallido debe reiniciarse desde el tercer punto de control porque los dos primeros pasos no son idempotentes.

Llamar «conocimiento tribal» a todo eso es demasiado impreciso para resultar útil. Lo separo en cuatro tipos porque cada uno necesita pruebas diferentes:

• Reglas de negocio: qué resultado pretende la organización para un caso dado.
• Comportamiento observado: qué hace realmente el sistema actual, incluidos los defectos de los que dependen otros consumidores.
• Práctica operativa: cómo las personas programan, recuperan, concilian y anulan decisiones del sistema.
• Justificación histórica: por qué existe una regla, tabla o solución provisional y qué podría romperse si desaparece.

Estas categorías suelen entrar en conflicto. Un experto puede describir la regla aprobada mientras producción sigue una excepción antigua. Un operador puede tener un procedimiento de recuperación seguro que ningún desarrollador conoce. Una responsable financiera puede llamar error a una diferencia de redondeo aunque un informe posterior dependa de ella. El equipo de reescritura debe mantener la distinción hasta que se tome una decisión explícita.

Por eso un organigrama sirve de poco como mapa del conocimiento. La persona que más sabe puede ser un analista de soporte capaz de predecir qué entrada bloqueará el proceso nocturno, o un antiguo desarrollador que ahora trabaja en operaciones. Hay que empezar por los eventos del sistema, no por los cargos: ¿a quién llaman cuando falla la facturación, quién aprueba la conciliación, quién entiende los registros rechazados y quién sabe por qué sigue ejecutándose una exportación que parece no usarse?

Las personas también se equivocan. La experiencia merece respeto, pero la memoria no es una prueba. Quienes conocen el sistema antiguo aportan hipótesis, ejemplos y contexto. Los tests y los registros convierten esas aportaciones en algo en lo que puede apoyarse la migración.

Las entrevistas necesitan casos, no recorridos

La forma más rápida de desperdiciar el tiempo de un experto es preguntarle: «¿Cómo funciona el sistema?». Obtendrá un recorrido por los menús y el camino ideal. Ninguno de los dos revela las condiciones que provocaron los diez últimos incidentes de producción.

Organice las entrevistas alrededor de casos concretos. Pida a la persona que traiga una transacción completada, otra rechazada, un ajuste manual, un reinicio y una salida que necesitó conciliación. Después, haga que repase qué vio, qué esperaba, qué cambió y cómo supo que el resultado era aceptable. Las grabaciones de pantalla pueden ayudar, pero el registro escrito debe recoger entradas y decisiones, no solo clics.

En estas sesiones utilizo un pequeño registro de afirmaciones. Cada fila contiene una afirmación, una fuente, un ejemplo representativo, una comprobación propuesta, un responsable y un nivel de confianza. Una fila podría decir: «Una cuenta suspendida puede recibir un abono, pero no un cargo», con el responsable de cobros como fuente, dos identificadores de transacción y un test de límite propuesto. Otra podría indicar: «Los operadores reinician JOB17 en STEP30 tras agotarse el tiempo», con el operador nocturno como fuente, el registro de ejecución pertinente y un test de recuperación todavía pendiente.

El campo de confianza evita que una conversación educada se convierta en una certeza falsa. Use etiquetas sencillas, como confirmado por tráfico, confirmado por un test repetible, respaldado por dos personas, recuerdo único y controvertido. La confianza describe las pruebas, no la antigüedad del empleado.

Haga preguntas incómodas. ¿Qué hace fuera del sistema? ¿De qué campos desconfía siempre? ¿Qué comprueba antes de aprobar una salida? ¿Qué mensaje de error significa «inténtelo de nuevo» aunque parezca definitivo? ¿Qué ocurrió la última vez que cambió esta regla? ¿Quién discrepa de su versión? Estas preguntas descubren hojas de cálculo paralelas, autorizaciones telefónicas y controles compensatorios que un análisis de código no puede ver.

Mantenga las sesiones lo bastante cortas para que los expertos sigan siendo precisos. Devuelva las afirmaciones para corregirlas en uno o dos días, mientras los ejemplos aún resultan familiares. Una transcripción es material en bruto, no documentación. Alguien debe resolver los nombres, adjuntar las pruebas y dividir las afirmaciones compuestas antes de que la sesión produzca materiales de migración.

La intención y la compatibilidad son cosas distintas

Una reescritura debe distinguir la política pretendida del comportamiento de compatibilidad, porque conservar cualquiera de los dos por accidente causa sorpresas costosas. Los equipos confunden a menudo «el negocio quiere esto» con «el programa antiguo hace esto». Las dos frases pueden apuntar en direcciones opuestas.

Para cada comportamiento importante, registre tres respuestas: qué hace el sistema antiguo, qué quiere la organización después de la reescritura y qué esperan los consumidores o informes existentes. Después, asigne un destino. Conservar significa que el sistema nuevo debe coincidir. Corregir significa que será distinto de forma intencionada y necesita una expectativa aprobada. Retirar significa que el comportamiento y sus consumidores desaparecen juntos. Desconocido significa que el cambio todavía no puede depender de él con seguridad.

Piense en un programa de facturación que redondea cada línea antes de sumar la factura. La política escrita dice que se sumen las líneas sin redondear y se redondee el total. Los clientes pueden haber recibido durante años facturas redondeadas por línea, mientras una importación del libro mayor espera los céntimos resultantes. «Arreglar» el cálculo dentro de la reescritura puede romper la conciliación aunque la nueva respuesta sea matemáticamente preferible.

La decisión no puede esconderse en la solicitud de cambios de un desarrollador. Finanzas debe elegir entre conservar el resultado, ajustar la interfaz contable o introducir la regla corregida a partir de un límite declarado. La batería de paridad codifica entonces el resultado elegido. La documentación registra por qué difieren los resultados antiguos y nuevos. Soporte recibe un ejemplo que puede reconocer.

En Working Effectively with Legacy Code, Michael Feathers usa tests para controlar el comportamiento existente antes de cambiarlo. La idea se aplica más allá del código fuente. Un test de caracterización indica qué ocurre ahora. No declara que el comportamiento sea correcto. El gobierno de la migración comienza donde termina la caracterización: una persona con autoridad decide qué se convierte en contrato.

Esta distinción también evita cargar a los expertos con una responsabilidad injusta. Quien recuerda una solución provisional no debería decidir por sí solo si sobrevive. Su trabajo consiste en exponer el comportamiento y sus consecuencias. Los responsables de negocio e ingeniería deciden su futuro por escrito.

Las afirmaciones deben convertirse en ejemplos ejecutables

El conocimiento se vuelve duradero cuando una afirmación puede hacer fallar un test. La prosa sigue siendo necesaria, pero permite que dos lectores imaginen condiciones límite distintas.

Siempre que sea posible, escriba los ejemplos en el límite del sistema. Capture la entrada mínima que activa la regla, el estado inicial relevante, las salidas esperadas y los efectos secundarios permitidos. Evite tests que comprueben secuencias de llamadas internas de la implementación antigua. Esos tests conservan la estructura en lugar del comportamiento y castigan cualquier modernización real.

Un registro de comportamiento puede ser lo bastante sencillo para que lo revise un experto:

{
  "case": "credit_on_suspended_account",
  "starting_state": {"status": "suspended", "balance": 12500},
  "input": {"type": "credit", "amount": 2500},
  "expected": {
    "accepted": true,
    "balance": 10000,
    "audit_code": "CR-SUSP"
  },
  "source": "collections_review_14"
}

Los valores necesitan unidad y significado. Si 12500 significa unidades monetarias menores, indíquelo en la convención del fixture. Si las fechas usan el día hábil local en vez de UTC, codifique esa condición. Muchos supuestos fallos de paridad son en realidad fixtures ambiguos.

Construya familias de tests alrededor de los límites, no un único ejemplo de referencia. Para la regla de la cuenta suspendida, pruebe un abono, un cargo, cero, el importe máximo aceptado, un cambio de estado durante el proceso y la repetición de la misma solicitud. El experto suele saber qué casos han causado problemas. El ingeniero sabe por dónde pueden filtrarse los límites de la implementación. Ambas perspectivas deben estar en la batería.

Registre por separado el resultado antiguo y el aprobado cuando sean distintos. Un arnés útil puede informar MATCH, APPROVED_DIFFERENCE, UNEXPLAINED_DIFFERENCE o NOT_COMPARABLE. Un aprobado o suspenso binario empuja a los equipos a aceptar cambios sin explicar solo para que un panel aparezca en verde.

CodeHero usa un arnés de paridad con tráfico de producción grabado mientras moderniza la arquitectura en vez de transcribir el código antiguo. La misma disciplina debe aplicarse al conocimiento experto: cada recuerdo importante necesita un caso reproducible, una decisión aprobada o un estado pendiente visible.

El tráfico de producción tiene puntos ciegos

El tráfico de producción grabado es la fuente más sólida para el comportamiento habitual, pero no contiene todas las reglas que debe conservar la reescritura. Muestra lo ocurrido durante el periodo de captura. Dice poco sobre rutas poco frecuentes de fin de año, recuperación ante desastres, funciones de emergencia sin uso, entradas rechazadas antes de llegar o eventos que los operadores repararon manualmente antes de registrarlos.

Trate el tráfico y el testimonio experto como fuentes complementarias. Empiece reproduciendo las solicitudes capturadas en los sistemas antiguo y nuevo, y compare los resultados visibles desde fuera. Agrupe las diferencias por punto de acceso, tipo de transacción, campo de salida y clase de error. Después muestre grupos representativos a quienes operan o son responsables de esos flujos. Identificarán una diferencia inocua de hora, un defecto conocido o una regla ausente mucho antes que un equipo leyendo diferencias sin procesar.

El tráfico necesita contexto para convertirse en un corpus estable. Oculte o tokenice los valores sensibles sin perder sus relaciones. Fije los datos de referencia que cambiarían entre ejecuciones. Registre las suposiciones de reloj, configuración regional, reglas de orden y respuestas de las dependencias. Conserve el identificador de captura original para que una investigación pueda rastrear un caso fallido sin copiar datos de producción en una incidencia.

Desconfíe del muestreo. Un punto de acceso concurrido puede inundar el corpus mientras una transacción infrecuente y de grandes consecuencias solo aparece una vez. Construya vistas de cobertura por evento de negocio y riesgo, no solo por número de solicitudes. Pregunte a los expertos qué eventos deben aparecer aunque no estén en ninguna captura reciente. Después construya casos sintéticos a partir de un ejemplo aprobado y ejecútelos contra el sistema antiguo cuando sea seguro.

No use la reproducción de tráfico como excusa para evitar decidir qué salidas importan. Una comparación byte a byte marcará identificadores generados, horas, orden y formatos irrelevantes. Una normalización excesiva puede ocultar un asiento contable ausente. Defina los campos observables y las tolerancias para cada clase de transacción. Un experto debe poder explicar por qué se ignora una diferencia.

Por último, mantenga una cuarentena para los casos que todavía no puedan compararse. Un mensaje puede invocar a un socio no disponible, depender de datos de referencia caducados o activar una acción irreversible. Los casos en cuarentena necesitan un responsable y un motivo. Si el equipo se limita a borrarlos del corpus, la incertidumbre desaparece del informe pero permanece en el sistema.

La documentación debe explicar las decisiones

Una buena documentación de migración dice al siguiente ingeniero qué promete el sistema, dónde se comprueba esa promesa y por qué existe una excepción. Un catálogo de pantallas y tablas envejece antes del cambio porque describe la forma antigua, no el nuevo contrato.

Asigne un registro compacto a cada comportamiento importante. Incluya el evento de negocio, las condiciones previas, los resultados aceptados y rechazados, el responsable autorizado, los identificadores de tests, la respuesta operativa y el historial de decisiones. Los enlaces internos del repositorio o sistema documental pueden conectar estos elementos, pero el contenido debe poder leerse sin abrir otras cinco páginas.

Los registros de decisión son especialmente importantes cuando la paridad se rompe a propósito. Indique el comportamiento antiguo, el elegido, los consumidores afectados, quién lo aprobó, la condición de despliegue y la señal de marcha atrás. Evite entradas vagas como «se corrigió el problema de cálculo». Escriba la diferencia exacta: «La factura nueva redondea el total una vez; el adaptador contable añade una línea de compensación a las facturas creadas antes de la fecha de la política».

Los manuales operativos necesitan el mismo trato. Una instrucción como «reinicie el lote si se bloquea» resulta peligrosa. Defina cómo detecta el bloqueo el operador, qué punto de control es seguro, qué efectos secundarios duplicados debe revisar, qué conciliación demuestra la finalización y cuándo debe escalar. Convierta en comprobaciones automáticas las condiciones previas seguras cuando sea posible. Deje explícitas las decisiones humanas cuando automatizarlas solo fingiría certeza.

La propiedad de la documentación debe cambiar con el sistema. Durante la migración, el experto antiguo puede verificar una regla mientras un ingeniero nuevo escribe el registro y el test. Después del cambio, el propietario del servicio es dueño de ambos. Esta autoría conjunta evita convertir al experto en secretario permanente de una plataforma que ya no opera.

La facilidad de búsqueda importa, pero una única base de conocimientos enorme no es la respuesta. Mantenga el comportamiento cerca de los tests ejecutables, los procedimientos cerca del servicio y las decisiones de política donde las revisan sus responsables. Use identificadores de caso coherentes en todos esos lugares. El identificador es el hilo; la consolidación forzada suele crear un cementerio.

Revise la documentación intentando realizar una tarea. Entregue un caso fallido a un ingeniero que no participó en la migración y pídale que explique el resultado esperado, localice el test y encuentre la ruta de recuperación. Su confusión es un defecto documental con un ejemplo reproducible.

Los expertos no deben convertirse en una cola

Los expertos del sistema antiguo deben tener autoridad real en la reescritura, pero hacer que cada decisión espere a una persona sustituye conocimiento oculto por un cuello de botella visible. La solución es un protocolo de revisión que reserve su atención para la ambigüedad y el riesgo.

Asigne a cada experto una función limitada. Puede ser responsable de afirmaciones de un área, aprobar ejemplos representativos, clasificar diferencias de paridad o verificar un manual. Indique qué decisiones puede tomar y cuáles requieren al responsable de negocio, seguridad o servicio. Una matriz RACI es opcional; una ruta de escalado explícita, no.

Prepare el material antes de solicitar una revisión. No invite a un operador a ver pasar miles de resultados. Agrupe diferencias, elimine el ruido conocido, seleccione ejemplos y formule la pregunta como decisión: ¿conservar, corregir, retirar o investigar? Incluya el caso de origen y la consecuencia posterior. Diez minutos de criterio experto pueden sustituir horas de búsqueda en registros.

Use cobertura de dos personas para áreas de consecuencias graves. Empareje al experto veterano con alguien que seguirá siendo responsable después del cambio. La segunda persona escribe el test o manual, lo demuestra y se ocupa de la siguiente pregunta relacionada. El experto corrige el trabajo en vez de dictar cada frase. Así la transferencia se vuelve observable.

Proteja el tiempo de manera formal. Una revisión de migración añadida a una carga operativa completa perderá frente al siguiente incidente, como debe ser. Los responsables deben retirar otras tareas, programar espacios de decisión y seguir las afirmaciones sin respuesta como riesgos de entrega. No mida la participación por asistencia a reuniones. Mida afirmaciones resueltas, ejemplos aprobados, diferencias inexplicadas cerradas y procedimientos de recuperación demostrados.

Vigile el teatro de aprobación. Si los revisores reciben cien páginas el viernes y una solicitud de firma el lunes, la firma no prueba nada. Las revisiones pequeñas y basadas en casos dejan un rastro útil y permiten que el desacuerdo aparezca pronto.

Compense a las personas por la función que el proyecto necesita y concrete su camino después del cambio. Algunas se convertirán en responsables de dominio, analistas de producto, operadores de servicio, diseñadores de tests o líderes de modernización. Otras quizá decidan marcharse. Un trato respetuoso no garantiza que se queden, pero el desprecio casi garantiza que las advertencias más útiles lleguen tarde o nunca.

Un desacuerdo es una señal de riesgo

Cuando dos expertos describen la misma regla de forma distinta, no promedie sus respuestas ni deje ganar al cargo más alto. El desacuerdo suele señalar una condición oculta: grupos de clientes, fechas, regiones, canales de entrada o estados de recuperación diferentes.

Escriba ambas afirmaciones en el registro y pida a cada persona un caso en el que se aplique su versión. Compare esos casos con las rutas del código, la configuración, el historial de datos, las incidencias y el tráfico. El objetivo es encontrar el predicado que haga coherentes ambas versiones, o demostrar que el sistema se comporta de manera incoherente.

Suponga que un operador dice que un pago rechazado puede repetirse con seguridad, mientras otro afirma que la repetición crea duplicados. Sus procedimientos pueden diferir porque una cola asigna un token de idempotencia y otro canal más antiguo no lo hace. Un test genérico de «los reintentos son seguros» ocultaría el límite exacto que la reescritura debe imponer.

Algunas disputas son sobre política y no sobre hechos. Producto quiere una anulación favorable al cliente; cumplimiento exige un rechazo absoluto; operaciones aplica un compromiso manual. El código no puede resolver ese conflicto. Nombre al responsable, muestre consecuencias concretas y registre la decisión junto a los tests que modifica.

El silencio también es una prueba. Un área sin responsable claro, tráfico reciente ni ejemplo repetible merece más atención, no menos. Los equipos suelen etiquetarla como no utilizada porque borrarla simplifica el plan. Revise planificadores, registros de acceso, archivos generados, importaciones posteriores y procedimientos ligados al calendario antes de retirarla. Si las pruebas siguen siendo débiles, aísle la función detrás de un control de cambio y supervise su demanda en vez de fingir certeza.

Mantenga los desacuerdos pendientes en los criterios de puesta en marcha. Cada uno necesita un responsable, un alcance afectado, una alternativa segura y un plazo. Una migración puede avanzar con incertidumbre conocida si el radio de impacto está limitado y la marcha atrás es real. No debería avanzar porque la incertidumbre desapareció del orden del día.

La parte social importa. Los expertos que teman ser culpados por cada discrepancia suavizarán las contradicciones. Revise el sistema, no la memoria de la persona. Recompense a quien aporte un contraejemplo problemático, porque ese ejemplo sale más barato antes del cambio que después.

La ausencia de expertos cambia el método

Si la persona que conocía el sistema ya se ha marchado, la reescritura aún puede avanzar, pero el equipo debe sustituir el recuerdo por una búsqueda de pruebas más deliberada. No nombre experto universal al empleado más cercano. Eso genera respuestas seguras de alguien que solo ha visto una parte del sistema.

Empiece por rastros de decisiones. Las incidencias muestran qué fallos importaron y quién participó. Las solicitudes de cambios explican por qué apareció una condición. Los registros de lotes y calendarios de planificación exponen el trabajo dependiente del tiempo. Los archivos de conciliación muestran qué consideraba oficial otro departamento. Las plantillas de soporte revelan errores recurrentes. El historial del código puede identificar a quienes revisaron un módulo aunque su autor ya no esté.

Construya un mapa de testigos a partir de esos rastros. Un testigo puede conocer un límite estrecho: el contable que recibe una exportación, el equipo asociado que envía un archivo, el analista de soporte que reconoce casos duplicados o el ingeniero de infraestructura que restauró la última ejecución fallida. Pregunte a cada uno solo por eventos que haya atendido directamente. Varias versiones acotadas son más seguras que una gran narración prestada.

Use el sistema antiguo como sujeto experimental cuando sea seguro. Clone un estado similar al de producción en un entorno aislado, cambie una entrada cada vez y registre salidas y efectos secundarios. Empiece por casos recuperados de los registros y después examine límites visibles en ramas, tablas de validación y manejo de errores. Nunca ejecute transacciones exploratorias contra procesos financieros, industriales o de clientes activos solo porque falte documentación.

El análisis estático puede encontrar reglas candidatas, pero no indica si una rama es política vigente, código muerto o un defecto antiguo que espera un consumidor. Marque las reglas extraídas como no confirmadas hasta que el tráfico, una ejecución repetible o un responsable las respalde. La ausencia de una persona hace más importantes las etiquetas de confianza.

Ajuste los controles del cambio a la incertidumbre restante. Un informe poco comprendido puede ejecutarse en paralelo para un conjunto definido de eventos. Una transacción rara e irreversible puede necesitar aprobación manual y una ruta de marcha atrás. Una exportación que parece no usarse puede mantenerse aislada y vigilada hasta que pase su activador de calendario. Estos controles cuestan tiempo, pero muestran el coste con honestidad.

A veces las pruebas nunca alcanzan suficiente solidez. La respuesta responsable es una excepción acotada con un propietario, un método de detección y un procedimiento de recuperación. Inventar certeza genera un informe más limpio y un incidente más sucio. La falta de un experto eleva la carga de la prueba; no la elimina.

Defina las pruebas mínimas de cada clase de riesgo antes de empezar a probar, para que la presión de entrega no rebaje el umbral más tarde.

El cambio modifica el trabajo, no la necesidad de criterio

Después de la reescritura, los expertos antiguos ya no deberían ser los únicos capaces de mantener el negocio en marcha. Su criterio sigue importando, pero debe actuar mediante tests, decisiones y procedimientos con propietario, no mediante llamadas de emergencia.

Defina la transición antes del cambio. Enumere cada responsabilidad recurrente: aprobar excepciones, conciliar salidas, actualizar datos de referencia, reiniciar trabajos, explicar informes y clasificar defectos. Nombre al nuevo responsable, el material de apoyo, una fecha de demostración y la condición de salida del antiguo experto. «Conocimiento transferido» no es una condición. «El nuevo responsable completó dos conciliaciones representativas y recuperó un lote fallido durante un ensayo» sí lo es.

Haga ensayos operativos con fallos realistas. Desactive una dependencia, introduzca un mensaje duplicado, caduque datos de referencia y fuerce un lote parcial. Los nuevos responsables deben diagnosticar y recuperar usando la nueva observabilidad y los manuales mientras el experto anterior observa. Cualquier pista susurrada se convierte después en una comprobación o instrucción ausente.

Mantenga a los expertos en un ciclo de revisión limitado durante la operación inicial, con rutas claras y una fecha de finalización. Deben examinar fallos de paridad nuevos y cuestiones de política, no aprobar cambios ordinarios para siempre. Si todos los problemas de producción siguen llegando a ellos, la migración movió el código sin mover la responsabilidad.

Conserve el entorno antiguo y sus pruebas según las normas legales, operativas y de datos. El equipo quizá necesite reproducir una salida discutida o explicar una transacción histórica. Eso no significa dejar un sistema sin mantenimiento conectado de forma indefinida. Defina acceso, aislamiento, conservación de datos y autoridad para ejecutarlo.

La prueba final es la ausencia. ¿Pueden los nuevos responsables operar un cierre, recuperar un fallo, responder a soporte y cambiar una regla documentada mientras el antiguo experto no está disponible? Si no, identifique las pruebas que faltan y vuelva a ensayar.

Una reescritura tiene éxito cuando la organización puede explicar su comportamiento sin folclore y cambiarlo sin convocar a una persona concreta. Quienes sostuvieron el sistema antiguo merecen más que una entrevista ceremonial. Déles casos precisos para juzgar, registre los desacuerdos que descubran y convierta su conocimiento en algo ejecutable. Así, el nuevo equipo recibe pruebas en vez de historias, y los expertos dejan un legado mejor que una guardia permanente.