Contenido verificado el 2026-07-06 · experimento de Eggthropic
Refactor de ABAP legacy a Clean ABAP con Claude
Tomar un report ABAP clásico de ausencias HCM con 13 defectos plantados y pedirle a Claude cuatro cosas en orden: revisión con severidades, refactor completo, riesgos y — la parte que casi nadie pide — cuándo NO refactorizar.
Objetivo
Comprobar si Claude puede revisar un report ABAP clásico contra la guía Clean ABAP oficial de SAP y producir un refactor completo que preserve la semántica, con riesgos documentados y criterios honestos de cuándo no tocar el código.
Contexto
La revisión y refactor de programas Z heredados es una tarea semanal real de cualquier consultor ABAP: SELECT anidados con patrón N+1, tablas con cabecera, fieldcat manual de 16 líneas, números mágicos y lógica imposible de testear. El experimento usa un report ficticio pero realista de ausencias SAP HCM (IT2001 + PA0001 + T554T) con 13 defectos inventariados a propósito antes de la prueba, para poder medir la detección contra una lista cerrada.
Prompt utilizado
Actúa como revisor senior de ABAP aplicando la guía Clean ABAP oficial de SAP. Contexto: release objetivo, módulo, motivo del refactor y restricciones. Haz exactamente esto, en orden: 1) REVISIÓN: problemas clasificados por severidad citando la regla Clean ABAP. 2) REFACTOR: reescribe el programa preservando la semántica; marca cualquier punto donde pueda variar. 3) RIESGOS: qué podría romperse y qué pruebas de regresión harías. 4) NO REFACTORIZAR: di explícitamente si en este caso no conviene tocar el código y por qué. No inventes tablas ni funciones; marca el resultado como pendiente de validación sintáctica en sistema real.
Notas de implementación
El flujo produce cuatro artefactos: review.md con los hallazgos por severidad, after.abap con el refactor (clase local, un único JOIN en vez de miles de accesos a BD, lógica separada del ALV y testeable, CL_SALV_TABLE, constantes con nombre), un checklist Clean ABAP reutilizable con sección específica HCM (delimitaciones, SPRPS, autorizaciones) y el prompt afinado. La estructura del prompt — revisión antes que refactor, y el paso 4 obligatorio — es lo que evita el sesgo de «refactorizar siempre».
Resultado
Detección 13/13 sobre los defectos inventariados, con severidades y regla Clean ABAP citada. El refactor produjo la estructura esperada. Matices honestos: el 13/13 es cota superior porque el mismo modelo escribió el código defectuoso; la primera versión del refactor usó un tipo de datos inadecuado que hubo que corregir en sesión; y sin sistema SAP nada se compila — todo el código va marcado como pendiente de validar en un sistema real.
Qué funcionó
- El orden revisión → refactor → riesgos → cuándo-no-refactorizar produce salidas completas y honestas en una sola pasada
- La sección «cuándo NO refactorizar» salió con criterios accionables: sin regresión definida, cerca de cierre de nómina o sobre código estable, no se toca
- El refactor eliminó el patrón N+1 con un único JOIN y dejó la lógica de negocio testeable con ABAP Unit
- El checklist resultante con sección HCM es reutilizable en revisiones manuales
Qué falló
- La primera versión usó /iwbep/t_cod_select_options como tipo de rango (dependencia innecesaria de Gateway) — corregido a TYPE RANGE OF: la salida necesita revisión humana siempre
- El 13/13 de detección tiene sesgo de auto-revisión: el mismo modelo plantó los defectos
- Sin sistema SAP no hay validación sintáctica ni comparación de salidas antes/después con datos
- El JOIN a PA0001 vigente asume un único registro válido: con delimitaciones no triviales la semántica podría variar
Próxima iteración
Prueba de control con un report Z real anonimizado que Claude no haya escrito: contar hallazgos correctos, falsos positivos y tiempo frente a una revisión manual. Si supera el control, convertir el flujo en una Agent Skill de revisión ABAP.
Reproducelo tú
Este experimento es un playbook: con las herramientas de arriba y el prompt exacto de esta página puedes repetirlo en tu propio entorno. Si lo haces — funcione o no — cuéntanoslo en GitHub: las réplicas con resultados distintos son tan valiosas como el experimento original.
This experiment has an interactive version in the Lab.
Open interactive lab