Goose Game Kata, réalisé en deux avec Github Copilot, pour aiguiser mes compétences d'ingénierie rapides et réfléchir aux modèles de communication à adopter lors de la jumelage avec un outil de codage assisté par AI? ...
Tout a commencé avec l'invite suivante:
J'aimerais faire un kata de codage avec vous, pour pratiquer le TDD, la refactorisation et la conception de logiciels. Nous essaierons de suivre TDD et ses étapes assez strictement. Nous allons coder le Kata à Kotlin, en utilisant une configuration de projet simple à Gradle. Le kata est le suivant: https://github.com/xpeppers/goose-game-kata. Nous allons commencer par la première fonctionnalité, avec le cycle TDD d'ajouter un test, de le faire passer, de refacter le code et de répéter. Nous travaillerons en petites étapes, itérativement.
La première fonctionnalité est la suivante:
1. Ajouter des joueurs
En tant que joueur, je veux m'ajouter au jeu pour que je puisse jouer.
Scénarios:
- Ajouter le joueur
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"
- Joueur dupliqué
If there is already a participant "Pippo"
the user writes: "add player Pippo"
the system responds: "Pippo: already existing player"
Vous allez écrire le premier test, puis je vais vous donner des commentaires sur sa qualité. Si le test est OK pour moi, nous allons passer à l'implémentation du code d'application que nous ferons passer le test. Ensuite, nous chercherons toute occasion de rendre le code plus clair, plus facile à comprendre en le refactorisant.
Parallèlement au code, vous pouvez trouver les invites que j'ai utilisées pour guider la session de programmation par paire dans les prompts > plus anciennes. J'ai créé un nouveau fichier d'invite pour chaque nouvelle étape que nous avons faite. Je mets plus d'invites dans le même fichier, séparés par une ligne --- , lorsqu'une seule invite n'a pas entraîné tous les tests.
Mes commentaires sur la réalisation de ce kata avec Copilot
- Je pense que je suis moins concentré sur le code résultant, plus concentré sur l'invite correcte et si la réponse "fonctionne" ou non
- J'ai remarqué que parfois je me concentre davantage sur la forme de l'invite et si le code compile et que les tests passent toujours plutôt que sur la forme du code ... parfois cela nous a conduits à une impasse, et nous avons dû revenir sur les modifications et recommencer.
- Il n'est pas clair à quel point le copilote est sensible à ce qui est mieux à faire après le refactorisation: refactor à volonté? Quand est-il logique de passer au test suivant?
- Souvent, les "spécifications" sont intrinsèquement ambiguës (que signifie "le jeu qui roule le dés"?) => Face à cette ambiguïté, il est très probable que la réponse du modèle ne soit pas la "bonne", à moins que nous ne réduisions l'ambiguïté dans l'invite nous-mêmes (assument ainsi le rôle de "DISAMBIGUATEURS", du "client")
- Parfois, les réponses du modèle me surprennent (par exemple, il parvient à bien comprendre le contexte et à modifier le code pour respecter le style et la forme du code existant), d'autres fois, il fait des erreurs qui semblent être des "erreurs de distraction" comme nous les humains?
- Copilot a une excellente fenêtre de contexte, il peut se rappeler que les choses aient déjà dit plusieurs invites.
- Lorsqu'il refactora ou propose des modifications, il ne se rend pas compte qu'il doit également réparer les tests ... il se concentre presque toujours uniquement sur le code d'application?
- Lorsque le code a besoin de refactorisation préparatoire pour s'adapter à la fonction suivante (le classique «d'abord, facilitez le changement, puis effectuez le changement facile»), Copilot lutte:
- Il ne semble pas être incapable de faire face à ce genre de raisonnement (comme dans "Nous devons prendre du recul et revoir les choses stratégiquement")
- Il ne parvient pas à identifier les odeurs "complexes" lorsque la logique dont nous avons besoin pour la prochaine fonctionnalité est dispersée sur plusieurs classes, nous devons donc prendre du recul avant d'avancer.
- Même si vous lui dites de commencer à zéro, en jetant tout le code produit à partir du test qui est resté rouge, il répète souvent les mêmes étapes, même si vous lui dites "essayons une nouvelle approche" ou "faisons choses en petites étapes ».
Voir aussi mes réflexions ici (italien)
