La clase de 4 800 líneas y dos fechas regulatorias encima

Por qué la reescritura es la peor opción ahora. Una reescritura de 4 800 líneas sin pruebas de referencia significa que nadie puede demostrar que el comportamiento nuevo es equivalente, y en facturación la equivalencia es requisito legal. Además, el negocio tiene dos fechas duras en 4 y 6 semanas: la reescritura no entrega valor en ese plazo y compite por las mismas personas que deben cumplir la resolución de la DIAN.

Conceptos aplicables.

• Seam (punto de costura): un lugar donde se puede cambiar el comportamiento sin editar el código en ese punto. Los 40 new directos son exactamente la ausencia de seams; introducirlos (pasar el generador de PDF y el cliente de correo por constructor) permite observar y sustituir dependencias sin reescribir la lógica.
• Prueba de caracterización: prueba que documenta lo que el código hace hoy, incluidos los comportamientos extraños, para detectar cambios accidentales durante el refactor. Su función no es validar lo correcto sino congelar lo actual.

Plan. Antes de tocar nada, capturar un lote de facturas reales (anonimizadas) como casos dorados: entrada, PDF esperado, totales. Convertirlas en pruebas de caracterización. Solo entonces refactorizar, con incrementos pequeños y siempre verdes.

Regla. La reescritura no se descarta para siempre, pero solo se justifica cuando el módulo ya está aislado por interfaces y con pruebas de contrato del comportamiento; hasta entonces es una apuesta.

Criterio de ordenamiento. Primero lo que reduce riesgo de las dos fechas, después lo que reduce acoplamiento, y al final la lógica de negocio pura. Extraer primero el cálculo de impuestos sería tentador, pero es justo lo que la DIAN va a cambiar: refactorizar y cambiar reglas al mismo tiempo impide distinguir si un fallo vino del refactor o de la norma.

Semana 1 - Seams y red de seguridad. Inyectar dependencias en los 40 puntos de new (generador de PDF, SMTP, conexión JDBC) sin cambiar lógica. Crear pruebas de caracterización con facturas reales. Objetivo: poder ejecutar en segundos lo que hoy toma 2 días manuales.

Semana 2 - Extraer efectos secundarios. Sacar el envío de correo y el logging a colaboradores propios. Son de bajo riesgo, no afectan el cálculo y eliminan ruido de las pruebas.

Semanas 3–4 - Extraer persistencia y generación de PDF detrás de interfaces (RepositorioFactura, GeneradorPdf). Aquí se cumple la resolución de la DIAN: el nuevo formato entra como una implementación nueva del generador, no como un parche a 4 800 líneas.

Semanas 5–6 - Extraer el cálculo a un objeto de dominio con pruebas propias, y construir la nota crédito sobre esa pieza ya aislada, reutilizando el cálculo de impuestos.

Justificación del orden. Cada paso entrega valor o reduce riesgo para una fecha; ninguno requiere una congelación total, y todos dejan el sistema funcionando al final del día.

Estrategia de rama y despliegue. Trabajar con cambios pequeños que entren a producción de forma continua, no con una rama de refactorización de seis semanas. La rama larga garantiza conflicto y una integración final de alto riesgo. Cada refactor debe ser un cambio de estructura sin cambio de comportamiento, verificable con las pruebas de caracterización; los cambios de comportamiento (nueva resolución, nota crédito) van en commits separados.

Protección de las fechas.

• Semana 4, resolución DIAN: se implementa como una nueva implementación de GeneradorPdf y un ajuste en el cálculo ya extraído. Si el refactor se atrasa, existe una ruta de emergencia: parche mínimo sobre el código actual, con la deuda registrada explícitamente.
• Semana 6, nota crédito: se construye sobre las piezas extraídas (cálculo y generación), no sobre FacturacionManager.

Gestión de riesgo.

1. Feature flag para activar el nuevo formato cuando la DIAN lo exija, con reversa inmediata.
2. Ejecución en paralelo (shadow): generar facturas con el código viejo y el nuevo y comparar totales; divergencia = alerta antes de afectar al cliente.
3. Criterio de aborto explícito: si al final de la semana 2 las pruebas de caracterización no cubren los flujos principales, se detiene el refactor y se cumple la fecha con parche.
4. Comunicación: informar semanalmente al negocio el estado del riesgo, no solo el avance.

Lo que no se debe hacer. Aceptar la reescritura «para el próximo semestre» sin haber estabilizado el módulo: repetiría el mismo problema con un equipo más cansado.