Refactorizar no es un lujo ni un capricho de puristas del código limpio. Es una disciplina financiera: cada mes que pasa sin limpiar la maraña, el equipo multiplica el tiempo de entrega de cada nueva funcionalidad y duplica el riesgo de introducir regresiones. He visto equipos enteros convencidos de que su prioridad era escribir código nuevo cuando, en realidad, su velocidad de entrega estaba secuestrada por una clase de 3000 líneas con dependencias ocultas. La solución correcta no pasa por reescribir el sistema desde cero —eso casi siempre termina en otra pesadilla—, sino por una estrategia metódica de refactorización quirúrgica.

Este tutorial parte de una premisa: refactorizas para reducir el coste de la siguiente entrega, no para dejar un repositorio bonito. A continuación tienes un método práctico, con indicadores objetivos, herramientas concretas y las salvaguardas que funcionan incluso cuando el equipo no tiene cultura de testing.

Qué refactorizar: evidencia en lugar de corazonadas

El error más caro es refactorizar el archivo que odias en lugar del archivo que perjudica la facturación del producto. Para decidir con datos, combina métricas cuantitativas y señales cualitativas. Una complejidad ciclomática superior a diez en una función, una profundidad de anidamiento mayor de tres niveles o una clase que supera las quinientas líneas son síntomas evidentes. Pero la señal más valiosa es la frecuencia de cambios: si un módulo pequeño recibe parches constantes para corregir efectos secundarios, ahí se concentra la deuda.

Recomiendo generar un mapa de hotspots a partir del historial de git. Identifica qué archivos acumulan más commits de corrección y qué funciones aparecen vinculadas a más incidencias en un período reciente. Un buen candidato tiene dos propiedades: abundan los defectos y cada corrección provoca otro fallo.

El ejemplo clásico es una pasarela de pagos con varias promociones. Imagina una función `calcularTotal` de ciento veinte líneas con ocho `if` encadenados que aplican descuentos, cupones y tarjetas regalo. En producción aparece un fallo donde un cupón caducado se restaba después del descuento corporativo. Lo arreglas, y dos semanas después detectas el caso inverso. Ese archivo te está cobrando peaje cada vez que cambia un filtro; ahí debes intervenir, no en el módulo de facturación que apenas se toca.

Prompt
Actúa como un consultor senior de refactorización. Analiza el repositorio [URL o ruta local] y prioriza los candidatos a refactorizar. Usa como criterio la frecuencia de commits de corrección, el recuento de incidentes asociados y la complejidad ciclomática de los archivos. Devuélveme una tabla priorizada con estos campos: archivo, severidad, riesgo estimado de la intervención y tipo de refactorización recomendada (extracción de función, division de clase, eliminación de condicionales anidados, etc.). No sugieras reescrituras completas.