goose game ai driven

El juego de ganso kata, hecho en pares con copilot Github, para agudizar mis rápidas habilidades de ingeniería y reflexionar sobre los patrones de comunicación para adoptar al combinar con una herramienta de codificación asistida por AI. ...

Todo comenzó con el siguiente mensaje:

Me gustaría hacer un Kata de codificación con usted, practicar juntos TDD, refactorización y diseño de software. Intentaremos seguir a TDD y sus pasos bastante estrictamente. Vamos a codificar el Kata en Kotlin, utilizando una configuración de proyecto simple en Gradle. El kata es lo siguiente: https://github.com/xpeppers/goose-game-kata. Comenzaremos con la primera característica, con el ciclo TDD de agregar una prueba, hacer que pase, refactorizar el código y repetir. Trabajaremos en pequeños pasos, iterativamente.

La primera característica es la siguiente:

---

1. Agregar jugadores

Como jugador, quiero agregarme al juego para poder jugar.

Escenarios:

1. Agregar jugador

If there is no participant
the user writes: "add player Pippo"
the system responds: "players: Pippo"
the user writes: "add player Pluto"
the system responds: "players: Pippo, Pluto"

2. Jugador duplicado

If there is already a participant "Pippo"
the user writes: "add player Pippo"
the system responds: "Pippo: already existing player"

Vas a escribir la primera prueba, y luego te daré comentarios sobre su calidad. Si la prueba está bien para mí, pasaremos para implementar el código de aplicación que realizaremos la prueba. Luego buscaremos cualquier oportunidad para hacer que el código sea más claro, más fácil de entender refactorizándolo.

---

Junto con el código, puede encontrar las indicaciones que usé para guiar la sesión de programación de pares en las prompts > más antiguas. Creé un nuevo archivo de solicitud para cada nuevo paso que hicimos. Puse más indicaciones en el mismo archivo, separados por una línea --- , cuando una sola solicitud no dio como resultado que todas las pruebas pasen.

Mis comentarios sobre cómo realizar este kata con copilot

• Siento que estoy menos centrado en el código resultante, más centrado en el aviso correcto y si la respuesta "funciona" o no
  • Noté que a veces me concentro más en la forma del aviso y si el código compilado y las pruebas aún pasan en lugar de en la forma del código ... a veces esto nos llevó a un callejón sin salida, y tuvimos que revertir los cambios. Y empieza de nuevo.
• No está claro qué tan sensible es el copiloto de lo que es mejor hacer después de refactorizar: ¿refactor de voluntad? ¿Cuándo tiene sentido pasar a la siguiente prueba?
• A menudo, las "especificaciones" son inherentemente ambiguas (¿qué significa "el juego tira los dados"?) => Frente con esta ambigüedad, es muy probable que la respuesta del modelo no sea la "correcta", a menos que reduzcamos la ambigüedad en el aviso nosotros mismos (asumiendo así el papel de los "desambiguadores", del "cliente")
• A veces, las respuestas del modelo me sorprenden (por ejemplo, logra comprender bien el contexto y modificar el código para respetar el estilo y la forma del código existente), otras veces comete errores que parecen "errores de distracción" como lo hacemos los humanos.
• Copilot tiene una excelente ventana de contexto, puede recordar que las cosas dijeron varias indicaciones antes.
• Cuando refactora o propone cambios, no se da cuenta de que también necesita corregir las pruebas ... ¿casi siempre se enfoca solo en el código de aplicación?
• Cuando el código necesita refactorización preparatoria para acomodar la siguiente característica (el clásico "Primero, facilite el cambio, luego haga el cambio fácil"), Copilot luchas:
  • No parece no poder enfrentar este tipo de razonamiento (como en "Necesitamos dar un paso atrás y revisar las cosas estratégicamente")
  • No identifica los olores "complejos" cuando la lógica que necesitamos para la próxima característica se dispersa en múltiples clases, por lo que debemos dar un paso atrás antes de avanzar.
  • Incluso si le dice que comience desde cero, tirando todo el código producido a partir de la prueba que permaneció en la barra roja, a menudo simplemente repite los mismos pasos, incluso si lo dice "intentemos un nuevo enfoque" o "Dayamos cosas en pequeños pasos ”.

Ver también mis reflexiones aquí (italiano)