nombre: descripción del refactor: Refactorización sistemática de código basada en la metodología de Martin Fowler. Use cuando los usuarios pidan refactorizar código, mejorar la estructura del código, reducir la deuda técnica, limpiar el código heredado, eliminar olores al código o mejorar la mantenibilidad del código.

Habilidad de refactorización de código

Un enfoque sistemático para refactorizar el código basado en el de Martin Fowler Refactorización: mejorar el diseño del código existente (2a edición). Esta habilidad enfatiza cambios seguros y incrementales respaldados por pruebas.

"La refactorización es el proceso de cambiar un sistema de software de tal manera que no altere el comportamiento externo del código pero mejore su estructura interna." — Martin Fowler

Principios básicos

1. Preservación del comportamiento: El comportamiento externo debe permanecer sin cambios
2. Pasos pequeños: Realizar pequeños cambios, testables
3. Conducida por el ensayo: Las pruebas son la red de seguridad
4. Continuo: La refactorización está en curso, no es un evento único
5. Colaboración: Se requiere la aprobación del usuario en cada fase

Resumen del flujo de trabajo

Phase 1: Research & Analysis
    ↓
Phase 2: Test Coverage Assessment
    ↓
Phase 3: Code Smell Identification
    ↓
Phase 4: Refactoring Plan Creation
    ↓
Phase 5: Incremental Implementation
    ↓
Phase 6: Review & Iteration

Fase 1: Investigación y análisis

Objetivos

• Comprender la estructura y el propósito de la base de código
• Identificar el alcance de la refactorización
• Recopilar contexto sobre los requisitos de negocio

Preguntas que debe hacer el usuario

Antes de comenzar, aclare:

1. Ámbito de aplicación: ¿Qué archivos/módulos/funciones necesitan refactorización?
2. Objetivos: ¿Qué problemas está tratando de resolver? (legibilidad, rendimiento, mantenimiento)
3. Limitaciones: ¿Hay áreas que NO deberían ser cambiadas?
4. Presión de la línea de tiempo: ¿Esto está bloqueando otro trabajo?
5. Estado del ensayo: ¿Existen pruebas? ¿Están pasando?

Medidas

• [ ] Leer y entender el código de destino
• [ ] Identificar dependencias e integraciones
• [ ] Arquitectura actual del documento
• [ ] Note los marcadores de deuda técnica existentes (TODO, FIXMEs)

Producto

Presente las conclusiones al usuario: - Resumen de la estructura del código - Esferas problemáticas identificadas - Recomendaciones iniciales Solicitar la aprobación para proceder

Fase 2: Evaluación de la cobertura del ensayo

Por qué las pruebas importan

"Refactorizar sin pruebas es como conducir sin cinturón de seguridad." — Martin Fowler

Las pruebas son la activador de teclas Sin ellos, corres el riesgo de introducir bichos.

Etapas de evaluación

1. Comprobación de los ensayos existentes bash # Look for test files find . -name "*test*" -o -name "*spec*" | head -20

2. Ejecutar pruebas existentes # JavaScript/TypeScript npm test

# Python pytest -v

# Prueba de Java mvn #

1. Control de la cobertura (si está disponible) Prueba de ejecución JavaScript npm:coverage

# Python pytest --cov=. #

Punto de decisión: Pregunte al usuario

Si existen pruebas y se aprueban: - Proceda a la fase 3

Si faltan pruebas o están incompletas: Opciones actuales: 1. Escribir pruebas primero (recomendado) 2. Agregar pruebas incrementalmente durante la refactorización 3. Proceder sin pruebas (riesgo - requiere reconocimiento del usuario)

Si las pruebas están fallando: - DETENER. Fijar las pruebas que fallan antes de refactorizar - Preguntar al usuario: ¿Deberíamos arreglar las pruebas primero?

Guías de escritura de pruebas (si es necesario)

Para cada función que se refactorice, asegúrese de que las pruebas cubren: - Happy path (operación normal) - Edge cases (inputs vacíos, null, limits) - Escenarios de error (inversiones inválidas, excepciones)

Utilice el ciclo "rojo-verde-refactor": 1. Escribir prueba de fallo (rojo) 2. Hacerlo pasar (verde) 3. Refactor

Fase 3: Identificación del olor de código

¿Qué son los olores de código?

Síntomas de problemas más profundos en código. No son errores, sino indicadores de que el código podría ser mejorado.

Código común huele a comprobar

Ver references/code-smells.md para el catálogo completo.

Referencia rápida

Pasos de análisis

1. Análisis automatizado (si hay scripts disponibles) bash python scripts/detect-smells.py <file>

2. Revisión manual

3. Pasear por el código sistemáticamente
4. Observe cada olor con ubicación y severidad

5. Categorizar por impacto (crítico/alto/medio/bajo)

6. Priorización Concéntrate en los olores que:

7. Bloquear el desarrollo actual
8. Causar errores o confusión
9. Afecta a las rutas de código más cambiadas

Salida: Informe sobre el olor

Presente al usuario: - Lista de olores identificados con ubicaciones - Evaluación de gravedad para cada - Orden de prioridad recomendado - Solicitar la aprobación de las prioridades

Fase 4: Refactorización de la creación del plan

Selección de refactorizaciones

Para cada olor, seleccione una refactorización apropiada del catálogo.

Ver references/refactoring-catalog.md para la lista completa.

Mapeo del olor a la refactorización

Estructura del plan

Usar la plantilla en templates/refactoring-plan.md.

Para cada refactorización: 1. Objetivo: ¿Qué código cambiará 2. Huele.: ¿Qué problema aborda 3. Refactorización: Qué técnica aplicar 4. Pasos: Micro-paso detallado 5. RiesgosLo que podría salir mal 6. Retorno: Cómo deshacer si es necesario

Enfoque por etapas

CRÍTICA: Introducir la refactorización gradualmente en fases.

Fase A: victorias rápidas (Bajo riesgo, alto valor) - Cambiar el nombre de las variables para la claridad - Extraer código duplicado obvio - Eliminar código muerto

Fase B: Mejoras estructurales (Riesgo medio) - Extraer métodos de funciones largas - Introducir objetos de parámetros - Mover métodos a clases apropiadas

Fase C: Cambios arquitectónicos (Riesgo superior) - Reemplazar condicionales con polimorfismo - Clases de extracto - Introducir patrones de diseño

Punto de Decisión: Plan Presente al Usuario

Antes de la implementación: - Mostrar un plan de refactorización completo - Explicar cada fase y sus riesgos - Obtener aprobación explícita para cada fase - Preguntar: "¿Debo proceder con la Fase A?"

Fase 5: Aplicación incremental

La regla de oro

"Cambiar → Prueba → Verde? → Comprometer → Siguiente paso"

Ritmo de aplicación

Para cada paso de refactorización:

1. Comprobación previa
2. Las pruebas están pasando (verde)

3. Compilaciones de código

4. Hacer UN pequeño cambio

5. Siga la mecánica del catálogo

6. Mantener los cambios mínimos

7. Verificar

8. Ejecutar pruebas inmediatamente

9. Comprobar si hay errores de compilación

10. Si las pruebas pasan (verde)

11. Comprometerse con mensaje descriptivo

12. Pase al siguiente paso

13. Si los ensayos fallan (rojo)

14. DETENER inmediatamente
15. Deshacer el cambio
16. Analizar lo que salió mal
17. Pregunte al usuario si no está claro

Comprometer estrategia

Cada compromiso debe ser: - Atómico: Un cambio lógico Reversible: Fácil de revertir - Descriptiva: Borrar el mensaje de confirmación

Ejemplo de mensajes de confirmación:

refactor: Extract calculateTotal() from processOrder()
refactor: Rename 'x' to 'customerCount' for clarity
refactor: Remove unused validateOldFormat() method

Presentación de informes sobre la marcha de los trabajos

Después de cada subfase, informe al usuario: - Cambios realizados - Pruebas que aún pasan? - Cualquier problema encontrado - Preguntar: "¿Continúa con el siguiente lote?"

Fase 6: Revisión e Iteración

Lista de comprobación posterior a la refactorización

• [ ] Todas las pruebas que pasan
• [ ] No hay nuevas advertencias/errores
• [ ] Código compila con éxito
• [ ] Comportamiento sin cambios (verificación manual)
• [ ] Documentación actualizada si es necesario
• [ ] La historia de la comisión está limpia

Comparación métrica

Ejecutar análisis de complejidad antes y después:

python scripts/analyze-complexity.py <file>

Mejoras actuales: - Líneas de cambio de código - Cambio de complejidad ciclomática - Cambio de índice de mantenimiento

Revisión del usuario

Resultados finales actuales: - Resumen de todos los cambios - Comparación de códigos antes/después - Mejoras métricas - Deuda técnica restante - Preguntar: "¿Estás satisfecho con estos cambios?"

Próximos pasos

Discuta con el usuario: - ¿Olores adicionales a la dirección? - ¿Refactorización de seguimiento de programación? - ¿Aplicar cambios similares en otros lugares?

Directrices importantes

Cuándo PARAR y Preguntar

Siempre pausa y consulta al usuario cuando: - Insegura sobre la lógica de negocio - El cambio puede afectar a API externas - La cobertura de pruebas es inadecuada - Es necesaria una decisión arquitectónica significativa - Aumenta el nivel de riesgo - Te encuentras con complejidad inesperada

Normas de seguridad

1. Nunca refactorice sin pruebas (a menos que el usuario reconozca explícitamente el riesgo)
2. Nunca hagas grandes cambios. - romper en pequeños pasos
3. Nunca omitas la ejecución de la prueba después de cada cambio
4. Nunca continuar si las pruebas fallan - arreglar o revertir primero
5. Nunca asumas - en caso de duda, pregunte

Qué NO hacer

• No combine la refactorización con las adiciones de características
• No refactorice durante emergencias de producción
• No refactorices el código que no entiendes
• No sobreingeniería - mantenerlo simple
• No refactorices todo a la vez.

Ejemplo de inicio rápido

Escenario: Método largo con duplicación

Antes:

function processOrder(order) {
  // 150 lines of code with:
  // - Duplicated validation logic
  // - Inline calculations
  // - Mixed responsibilities
}

Pasos de refactorización:

1. Asegurarse de que existen pruebas para processOrder()
2. Extracto validación en validaOrden()
3. Ensayo - debe pasar
4. Extracto cálculo en el cálculoOrdenTotal()
5. Ensayo - debe pasar
6. Extracto notificación al cliente()
7. Ensayo - debe pasar
8. Revisión - processOrder() ahora orquesta 3 funciones claras

Después:

function processOrder(order) {
  validateOrder(order);
  const total = calculateOrderTotal(order);
  notifyCustomer(order, total);
  return { order, total };
}

Bibliografía

• Catálogo de olores de código - Lista completa de olores de código
• Catálogo de refactorización - Técnicas de refactorización
• Plantilla de plan de refactorización - Plantilla de planificación

Scripts

• scripts/analyze-complexity.py - Analizar las métricas de complejidad del código
• scripts/detect-smells.py - Detección automatizada de olores

Historial de la versión

• v1.0.0 (2025-01-15): Lanzamiento inicial con metodología Fowler, enfoque escalonado, puntos de consulta al usuario

Última actualización: 4 de agosto de 2026 Versión de Claude Code: 2.1.220 Fuentes: - https://code.claude.com/docs/en/skills Modelos compatibles: Claude Fable 5, Claude Opus 5, Claude Sonnet 5, Claude Sonnet 4.6, Claude Opus 4.8, Claude Haiku 4.5