# Planificación de refactorización

Reestructura el código sin cambiar lo que hace — en pasos lo bastante pequeños para verificarlos, y nunca en el mismo paso que un cambio de comportamiento.

## Entregable

Un documento Markdown, `refactoring-plan.md`, con la estructura fijada en **Salida** más abajo. Cada paso se ejecuta y se revisa por separado, y **Revisión de código** es la comprobación que se aplica entre ellos.

## Entradas obligatorias

- **El código que se va a reestructurar** — los archivos, módulos o el área, con acceso para leerlos.
- **El motivo de la reestructuración** — qué es difícil ahora y qué debería ser más fácil después. Reestructurar sin motivo declarado no tiene línea de meta.
- **La cobertura de pruebas actual de ese código**, o el medio para determinarla.

Si falta cualquiera de las tres, detente y reporta cuál. En particular, una refactorización planificada sin saber qué cubren las pruebas es una reescritura con optimismo encima.

## Entradas opcionales

- El comportamiento que se cree que tiene el código, en la forma escrita que exista
- Características de rendimiento que deben preservarse
- Llamadores y dependientes dentro y fuera del módulo
- El historial de control de versiones del área, incluidos intentos anteriores
- Restricciones de despliegue o de publicación sobre el área
- Cambios ya planificados sobre el mismo código, y cuándo entran

Cuando falta una entrada opcional, el plan nombra los pasos que habría restringido y los marca `sin verificar`, en lugar de seguir como si la restricción no existiera.

## Ejecución

**1 — Declarar la condición final.** Qué debe ser cierto cuando la refactorización termine, en términos que alguien pueda comprobar: la estructura, el límite, la dependencia que ya no existe. Una refactorización sin condición final sigue hasta que alguien se cansa.

**2 — Montar la red de seguridad.** Determina qué cubren de verdad las pruebas existentes sobre este código. Donde el comportamiento no esté fijado, escribe pruebas de caracterización que registren lo que el código hace hoy — incluido el comportamiento que parece incorrecto. Esas pruebas entran ANTES del primer paso de refactorización, como su propio paso.

**3 — Separar la reestructuración del cambio de comportamiento.** Lista todo lo que hará el trabajo y divídelo en dos listas: cambios que preservan el comportamiento y cambios que lo alteran. Los dos nunca ocurren en el mismo paso, y el plan dice qué pasos pertenecen a cada lista.

**4 — Partir el trabajo en pasos reversibles.** Cada paso es una transformación, verificable por sí sola y reversible por sí sola sin deshacer los pasos anteriores. Un paso que no se pueda revertir solo se divide hasta que se pueda.

**5 — Fijar el punto de control tras cada paso.** Las pruebas que deben pasar, el comportamiento que debe quedar igual, y cómo se observa. Las pruebas de caracterización del paso 2 se ejecutan en cada punto de control, sin modificar — una prueba editada durante una refactorización deja de ser evidencia.

**6 — Nombrar el punto de no retorno.** El paso tras el cual revertir cuesta más que continuar, normalmente donde cambia una forma de datos, una interfaz publicada o un formato almacenado. Todo lo anterior es barato de deshacer; todo lo posterior es un compromiso, y el plan lo dice.

**7 — Listar lo que la refactorización no tocará.** El código que se queda como está, y las mejoras dejadas deliberadamente para después. El alcance que crece dentro de una refactorización es lo que la convierte en una caída del servicio.

## Salida

`refactoring-plan.md`, en este orden:

- **1. Entrada y motivo** — el código, por qué se reestructura, y cuándo se escribió el plan
- **2. Condición final** — qué debe ser cierto al terminar, enunciado de forma que se pueda comprobar
- **3. Evaluación de cobertura** — qué fijan las pruebas existentes, y qué no
- **4. Pruebas de caracterización** — las pruebas que se escriben primero, qué registra cada una, y dónde viven
- **5. Pasos** — ordenados; por paso: la transformación, los archivos, si preserva el comportamiento, y cómo revertirlo
- **6. Puntos de control** — tras cada paso: qué se ejecuta, qué debe pasar, qué debe quedar igual
- **7. Cambios de comportamiento** — separados; cada uno con el paso al que pertenece y por qué no va en un paso de refactorización
- **8. Punto de no retorno** — el paso, qué lo hace irreversible, y qué debe decidirse antes
- **9. Fuera de alcance** — qué se deja deliberadamente intacto

## Validación

El plan está listo cuando se cumple todo esto:

- La sección 4 entra antes del primer paso de la sección 5
- Cada paso de la sección 5 está marcado como preservador del comportamiento o listado en la sección 7, nunca las dos cosas
- Cada paso nombra cómo revertirlo sin deshacer los pasos anteriores
- Cada punto de control nombra las pruebas que se ejecutan y declara que no se han modificado
- La sección 8 nombra un paso, o declara que ningún paso es irreversible
- La sección 2 está escrita de modo que alguien distinto de quien la escribió pueda ver cuándo se cumple

Falla la ejecución si un solo paso reestructura y cambia el comportamiento a la vez, o si un paso entra antes que las pruebas que lo cubren.

## Gestión de fallos

- **Sin cobertura de pruebas y sin forma de añadirla** — detente. Informa de que aquí no se puede verificar un cambio que preserve el comportamiento, y de que las únicas opciones honestas son añadir primero una forma de observar el comportamiento o tratar el trabajo como una reescritura con su propia especificación.
- **Sin motivo declarado** — detente. Informa de que la refactorización no tiene condición final y se juzgaría por gusto.
- **Cobertura desconocida** — planifica solo el paso 2, entrégalo y declara que los pasos restantes no se pueden escribir hasta saber qué fijan las pruebas.
- **El motivo exige un cambio de comportamiento** — dilo con claridad, separa el trabajo en una refactorización y un cambio, y planifícalos como secuencias distintas con aprobaciones distintas.
- **El área está en cambio activo** — lista el trabajo en conflicto en la sección 9 y, o bien secuencia la refactorización alrededor de él, o declara que los dos no pueden avanzar a la vez.