2153. Identidad de la lección
2154. Objetivo de aprendizaje
Después de esta lección, podrás dividir una solicitud amplia que afecta a varios sistemas en etapas secuenciadas, definir la evidencia de compatibilidad de cada etapa e identificar cuándo la incertidumbre exige escalar la decisión antes de implementar.
2155. Por qué importa
Una solicitud amplia puede parecer una sola funcionalidad aunque atraviese varios límites de responsabilidad. En un código de juego, cambiar el comportamiento visible también puede afectar el estado, la persistencia, la interfaz, la configuración, las pruebas y las herramientas. Pedirle a un agente de IA que complete toda la solicitud de una vez oculta esos límites y dificulta la revisión. Un plan escalonado da a cada cambio un propósito limitado, una dependencia clara y un punto de comprobación observable.
2156. Conocimientos previos
Debes poder mapear la propiedad dentro de un repositorio desconocido mediante el enfoque S-E-D-B de la lección anterior: identificar sistemas, puntos de entrada, propietarios de datos y límites. También debes distinguir la evidencia encontrada en el repositorio de las suposiciones derivadas de una solicitud. Esta lección no exige implementar el cambio.
2157. Concepto central
El concepto central es la secuenciación para controlar el cambio.
Una solicitud que afecta a varios sistemas debe dividirse según las dependencias y el riesgo, no simplemente según los nombres de los archivos. Cada etapa debe responder cuatro preguntas:
- ¿Qué resultado concreto establece esta etapa?
- ¿Qué comportamiento o interfaz existente debe seguir siendo compatible?
- ¿Qué evidencia demostrará que es suficientemente segura para continuar?
- ¿Qué incertidumbre o condición de fallo obliga a detenerse y escalar?
Una buena secuencia avanza desde un contrato explícito hacia el comportamiento y la integración. Evita combinar en una sola edición opaca un cambio de datos no verificado, un cambio de reglas y un cambio de presentación. Cuando sea posible, planifica el trabajo aislado alrededor de una responsabilidad y detente en un punto de control revisable antes de cruzar el siguiente límite entre sistemas.
2158. Modelo mental
Usa la secuencia Contrato → Núcleo → Integración → Limpieza:
| Etapa | Propósito | Pregunta de compatibilidad | Evidencia antes de continuar |
|---|---|---|---|
| Contrato | Definir entradas, salidas, cambios de estado y valores predeterminados | ¿Los llamadores existentes pueden seguir usando la interfaz? | Se identifican el contrato escrito, los llamadores afectados y el comportamiento predeterminado |
| Núcleo | Implementar o aislar la regla o transformación central | ¿El comportamiento principal funciona sin sistemas ajenos? | Comprobaciones enfocadas demuestran el comportamiento esperado y sus casos límite |
| Integración | Conectar el cambio central con otros sistemas y con la presentación | ¿Qué límites intercambian ahora los datos o eventos modificados? | Comprobaciones entre sistemas muestran que los recorridos antiguo y nuevo funcionan según lo previsto |
| Limpieza | Eliminar adaptadores temporales, rutas obsoletas o lógica duplicada | ¿Es segura la eliminación para todos los llamadores y estados guardados conocidos? | Búsquedas, pruebas y evidencia de migración o reversión respaldan la eliminación |
La secuencia no es una receta obligatoria de cuatro cambios. Es una herramienta de decisión. Una solicitud pequeña puede combinar etapas; una solicitud de alto riesgo puede dividir una etapa en varios puntos de control. El plan debe conservar el razonamiento aunque cambie el número de pasos de implementación.
2159. Ejemplo concreto
Considera esta solicitud amplia: “Añadir un objeto de desguace que pueda recogerse en el mundo, guardarse en el inventario del jugador, mostrarse en el HUD y utilizarse en una pantalla de intercambio”.
Un plan sin control pediría al agente editar de una vez las definiciones de objetos, la lógica de recogida, el modelo de inventario, el HUD, la pantalla de intercambio y las pruebas.
Un plan escalonado podría ser:
- Contrato: Rastrear la identidad del objeto, la representación del inventario y la entrada del intercambio. Definir el identificador, las reglas de acumulación, la cantidad inicial y el comportamiento cuando una partida antigua no contiene el objeto. Evidencia: se enumeran los llamadores relevantes y el límite de persistencia.
- Núcleo: Añadir los datos del objeto y el comportamiento del inventario sin modificar todavía el HUD ni la pantalla de intercambio. Evidencia: comprobaciones enfocadas cubren añadir, retirar, acumular y manejar una cantidad insuficiente.
- Integración: Conectar la recogida con el inventario y después conectar las lecturas del inventario con el HUD y la pantalla de intercambio. Mantener comprobaciones separadas para recogida, presentación y validación del intercambio. Evidencia: cada límite se prueba con el objeto nuevo y con uno existente.
- Limpieza: Eliminar cualquier adaptador temporal o identificador duplicado solo después de que las búsquedas no encuentren llamadores restantes y pasen las comprobaciones de compatibilidad. Evidencia: no queda una ruta obsoleta y el comportamiento alternativo sigue contemplado.
La decisión importante no es el orden exacto de los archivos. Es separar los contratos, el comportamiento central y las conexiones entre sistemas para que un fallo pueda localizarse.
2160. Flujo de trabajo nativo de IA
Usa la IA para ampliar y cuestionar el plan, no para sustituir la evidencia del repositorio.
- Expón al asistente la solicitud amplia y las restricciones conocidas.
- Pídele que proponga límites entre sistemas, dependencias, riesgos de compatibilidad y una secuencia de etapas. Exige que clasifique cada afirmación como evidencia del repositorio, inferencia o pregunta abierta.
- Compara la propuesta con el mapa S-E-D-B de la lección anterior. Comprueba en el repositorio cada sistema, punto de entrada y propietario de datos que haya mencionado.
- Pide al asistente que identifique el punto de control útil más pequeño para cada etapa y la evidencia necesaria antes de pasar a la siguiente.
- Rechaza o modifica cualquier etapa que combine límites de propiedad no relacionados, carezca de una condición de compatibilidad o suponga una interfaz que aún no se ha verificado.
- Registra explícitamente las condiciones de escalamiento. Algunos ejemplos son un formato de persistencia desconocido, propietarios en conflicto, un orden de eventos poco claro, la ausencia de pruebas para un límite crítico o un cambio que rompería un llamador existente.
La persona que aprende sigue siendo responsable de seleccionar la secuencia. La IA puede revelar omisiones, pero un plan verosímil no demuestra que el repositorio lo permita.
2161. Error común
El error común es creer que “escalonado” significa “editar un archivo por vez”. El número de archivos no es el mecanismo de control. Una etapa puede seguir siendo incontrolable si atraviesa varios límites de responsabilidad sin contrato ni punto de comprobación. Por el contrario, una etapa coherente puede tocar varios archivos cuando estos implementan una responsabilidad verificada. Los límites deben seguir las dependencias, la compatibilidad y la evidencia, no un número arbitrario de archivos.
2162. Práctica guiada
Trabaja con esta solicitud:
“Añadir una habilidad de escudo temporal. El jugador puede activarla, la habilidad consume un recurso, los enemigos no deben dañar al jugador mientras está activa, el HUD debe mostrar la duración restante y el estado debe sobrevivir a una transición de escena.”
Crea un plan escalonado sin editar el proyecto.
- Enumera los sistemas y límites que deben verificarse usando S-E-D-B.
- Escribe un resultado de una sola frase para cada etapa propuesta.
- Para cada etapa, indica la pregunta de compatibilidad y la evidencia necesaria para continuar.
- Marca al menos dos condiciones de escalamiento. Incluye una relacionada con el estado o la persistencia y otra relacionada con la propiedad en conflicto o el orden de los eventos.
- Pide a un asistente de IA que critique tu plan. Exige que señale dependencias omitidas sin inventar datos del repositorio.
- Modifica el plan solo cuando puedas explicar la evidencia que respalda la modificación.
Tu decisión principal es dónde colocar el límite entre la regla central del escudo y su integración con el daño, el consumo de recursos, la presentación del HUD y el estado durante la transición de escena.
2163. Validación / evidencia
Tu trabajo es suficiente cuando puedes señalar un plan escrito que contenga:
- Un resultado delimitado para cada etapa.
- Un orden de dependencias justificado por evidencia del repositorio o identificado claramente como pregunta abierta.
- Una condición de compatibilidad para cada etapa.
- Un punto de control revisable u observación comprobable para cada etapa, preferiblemente después del trabajo aislado y antes de cruzar el siguiente límite.
- Condiciones explícitas de escalamiento para propiedad, persistencia, orden de eventos o riesgo de interfaz aún no resueltos.
- Ninguna etapa descrita únicamente como “pedirle a la IA que implemente la funcionalidad”.
Como comprobación personal, elimina una etapa propuesta de tu plan. Si no puedes explicar qué dependencia, comprobación de compatibilidad o punto de evidencia desaparece, quizá las etapas originales no estaban realmente separadas.
2164. Puntos clave
- Secuencia el trabajo entre varios sistemas según dependencias, compatibilidad y evidencia, no según el número de archivos.
- Separa contrato, comportamiento central, integración y limpieza cuando cada preocupación tenga un riesgo distinto.
- Una etapa solo es revisable cuando su resultado y la evidencia para continuar están explícitos.
- El trabajo aislado y los puntos de control revisables facilitan localizar fallos antes de modificar el siguiente límite entre sistemas.
- La IA puede proponer dependencias y cuestionar omisiones, pero la evidencia del repositorio determina el plan.
- Escala la decisión cuando la propiedad, la persistencia, el orden de eventos o la compatibilidad sigan siendo inciertos.
2165. Próxima lección
Continúa con 5.7 — Refactoring.
2166. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué debe determinar principalmente los límites entre las etapas?
Mostrar respuesta y explicación
Respuesta: La dependencia, la compatibilidad y la evidencia necesaria para continuar.
Por qué: Los límites de etapa útiles siguen las dependencias, preservan la compatibilidad y definen la evidencia necesaria para avanzar. El número de archivos o el orden visual por sí solos no controlan el riesgo.
¿Qué pregunta debe aparecer en cada etapa de un plan de cambio entre varios sistemas?
Mostrar respuesta y explicación
Respuesta: ¿Qué comportamiento o interfaz existente debe seguir siendo compatible?
Por qué: Una pregunta de compatibilidad muestra qué debe preservar la etapa mientras modifica el sistema. Sin ella, la etapa no tiene un límite de seguridad explícito.
¿Cuándo debe escalarse un cambio entre varios sistemas antes de continuar con la implementación?
Mostrar respuesta y explicación
Respuesta: Cuando la propiedad, la persistencia, el orden de los eventos o la compatibilidad siguen siendo inciertos.
Por qué: El escalamiento es apropiado cuando una incertidumbre no resuelta podría hacer que el siguiente cambio fuera inseguro o difícil de revisar. El plan debe detenerse en lugar de ocultarla.
¿Cuál es el papel adecuado de la IA al planificar un cambio amplio en un repositorio?
Mostrar respuesta y explicación
Respuesta: Proponer dependencias y cuestionar omisiones mientras la persona verifica la evidencia.
Por qué: La IA resulta útil para ampliar y criticar un plan, pero la persona debe verificar los hechos del repositorio y conservar la responsabilidad de la secuencia.