Rechazar una abstracción atractiva pero insegura

2182. Identidad de la lección

Módulo

5.7 — Refactorización

Lección

Rechazar una abstracción atractiva pero insegura

Tipo académico

Estudio de caso

Tipo de esquema

estudio de caso

Orden

Lección 2 del módulo

Tiempo estimado

30–40 minutos, incluido el ejercicio de decisión

2183. Objetivo de aprendizaje

Después de esta lección, podrás explicar por qué una refactorización propuesta por la IA debe reducirse, posponerse o rechazarse, evaluando su complejidad, los límites de responsabilidad y el coste de la abstracción.

2184. Por qué importa

Las refactorizaciones generadas por IA suelen parecer profesionales porque reducen código repetido e introducen interfaces reutilizables. Esa apariencia no demuestra que la abstracción encaje con el juego. Una abstracción puede ocultar diferencias importantes, repartir la responsabilidad entre sistemas sin relación y dificultar el razonamiento sobre el comportamiento futuro. Rechazar una refactorización es una decisión técnica cuando el diseño propuesto crea más riesgo que valor.

2185. Conocimientos previos

Debes poder:

• identificar un contrato de comportamiento antes de modificar el código;
• comparar el comportamiento observable antes y después de una refactorización;
• distinguir una limpieza local de un cambio de responsabilidad;
• aplicar el principio de la lección anterior: refactorizar sin cambiar el contrato.

2186. Concepto central

Una abstracción se justifica por un comportamiento compartido y estable, no por una similitud superficial.

Dos fragmentos pueden parecer iguales y, sin embargo, representar reglas distintas, tener responsables diferentes o cambiar por motivos diferentes. Generalizarlos demasiado pronto crea un impuesto de abstracción: conceptos adicionales, indirección, configuración y coordinación que habrá que mantener en cada cambio futuro. Una refactorización segura conserva el contrato y mantiene clara la responsabilidad. Si la abstracción propuesta no cumple esas condiciones, hay que reducirla, posponerla o rechazarla.

Usa estas cuatro preguntas:

2187. Modelo mental

Prueba del coste de abstracción

Trata una abstracción propuesta como una decisión, no como una mejora automática:

Duplicación observada → ¿Contrato compartido? → ¿Responsable compartido? → ¿Menor complejidad total? → Aceptar, reducir, posponer o rechazar

Aplica esta tabla:

La pregunta no es «¿Se puede hacer genérico?». La pregunta es «¿Facilitará y permitirá verificar el próximo cambio correcto?».

2188. Ejemplo concreto

Una IA revisa dos sistemas locales de un prototipo:

1. Una interacción con un objeto recogible comprueba la cercanía del jugador, concede un objeto y elimina el objeto del escenario.
2. Una interacción con una puerta comprueba la cercanía, verifica una condición de acceso y cambia el estado de la puerta.

La IA propone un sistema genérico Interactable con una interfaz común, una cola de interacciones, un objeto de contexto, un tipo universal de resultado, un bus de eventos y una cadena de validación configurable. La propuesta resulta atractiva: ambos sistemas muestran un aviso de interacción y responden a la proximidad.

No debe aceptarse tal como está. La similitud visible es limitada, mientras que las reglas y las responsabilidades son distintas. La lógica del objeto recogible pertenece a la adquisición de objetos; el acceso y el estado de la puerta pertenecen a la puerta o al sistema de acceso. Un aviso compartido o una comprobación de distancia podrían ser una extracción reducida si tienen un contrato estable. La cola, el bus de eventos y el modelo de resultado generalizado no se justifican solo con este ejemplo.

Una respuesta adecuada para la IA sería:

«No introduzcas el sistema genérico de interacción. Mantén separadas las reglas del objeto recogible y de la puerta. Extrae primero únicamente la comprobación de proximidad si sus entradas y fallos son idénticos. Registra el resto de la duplicación como una posible tarea posterior y verifica que el contrato de interacción no cambie».

No se está rechazando toda mejora del código. Se está rechazando la incorporación de responsabilidades e indirección especulativas.

2189. Flujo de trabajo nativo de IA

Usa la IA para generar propuestas y críticas, no como autoridad para decidir si una generalización es segura.

1. Pide a la IA que describa los contratos actuales, los responsables y las diferencias entre los sistemas candidatos.
2. Pídele que separe la duplicación verificada de los requisitos futuros especulativos.
3. Solicita la refactorización mínima y una lista de la complejidad que añadiría la abstracción mayor.
4. Compara la propuesta con el código real y con la línea base de comportamiento de la lección anterior.
5. Elige una decisión: aceptar una extracción reducida, posponer la generalización o rechazar la abstracción.
6. Si implementas un cambio, mantenlo acotado y repite las comprobaciones de comportamiento. No aceptes un marco general solo porque el código generado compile.

Puedes usar este prompt:

«Analiza esta abstracción propuesta como una revisión de riesgos. Enumera el contrato compartido, las reglas distintas, el responsable de cada regla, la nueva indirección, la configuración añadida y las pruebas necesarias. Recomienda aceptar, reducir, posponer o rechazar. No escribas código hasta justificar la recomendación».

2190. Error común

El error más común es confundir sintaxis repetida con responsabilidad repetida. Es fácil aceptar una clase base, un gestor o un sistema de eventos genérico porque acorta el cambio actual. Sin embargo, eso puede trasladar la toma de decisiones lejos del sistema que posee la regla. El resultado es un código más abstracto pero menos claro, controlado por banderas y callbacks en lugar de contratos directos.

Otro error es usar «quizá lo necesitemos después» como prueba de que la abstracción se necesita ahora. Una posible característica futura no es un requisito actual. Conserva un diseño local y claro hasta que un segundo caso real demuestre un contrato común y estable.

2191. Evaluación práctica

Memo de decisión sobre el caso

El cuestionario es una comprobación formativa de conocimientos. Este memo de decisión es la evaluación práctica puntuable de la lección.

Revisa esta propuesta:

«El juego tiene tres sistemas con una comprobación canActivate(): una estación de curación, una puerta cerrada y un activador de misión. Crea una clase base Activatable con condition, cost, onActivate y onFailure como callbacks universales. Dirige todas las activaciones mediante un ActivationManager para poder añadir dispositivos futuros sin escribir código nuevo».

Redacta un breve memo de decisión con estas cinco partes:

1. Comportamiento compartido: identifica qué es realmente común y qué solo parece común.
2. Responsabilidad: indica qué sistema debe poseer cada regla: curación, acceso o progresión de misión.
3. Coste de abstracción: enumera al menos tres costes introducidos por la clase base y el gestor.
4. Decisión: elige aceptar de forma limitada, posponer o rechazar, y justifica tu elección con evidencias del caso.
5. Siguiente paso seguro: especifica el cambio mínimo, si existe, que pueda implementarse y verificarse sin cambiar el comportamiento.

Tu decisión debe incluir una razón concreta, no solo una preferencia de estilo.

2192. Validación / evidencias

2193. Conclusiones clave

• Una sintaxis parecida no demuestra que exista un contrato ni un responsable común.
• El coste de una abstracción incluye indirección, configuración, coordinación y esfuerzo de verificación.
• Generaliza el comportamiento estable, no las características futuras especulativas.
• Extraer una parte pequeña, posponer o rechazar puede ser la decisión correcta de refactorización.
• La IA puede mostrar opciones y riesgos; el desarrollador debe juzgar si la abstracción encaja con el juego.

2194. Próxima lección

Siguiente: continúa con 5.8 — Revisión de código con IA, donde aplicarás criterios disciplinados de revisión a cambios asistidos por IA.

2195. Comprobación