goose game ai driven

Gänsespiel Kata, praktisch mit Github Copilot, um meine schnellen technischen Fähigkeiten zu schärfen und über die Kommunikationsmuster nachzudenken, die sie bei der Kombination mit einem AI-unterstützten Codierungswerkzeug übernehmen sollen? ...

Alles begann mit der folgenden Eingabeaufforderung:

Ich möchte mit Ihnen eine kodierende Kata machen, um gemeinsam TDD, Refactoring und Software -Design zu üben. Wir werden versuchen, TDD und seine Schritte ziemlich ausschließlich zu folgen. Wir werden die Kata in Kotlin mit einem einfachen Projekt -Setup in Gradle codieren. Die Kata ist Folgendes: https://github.com/xpeppers/goose-game-kata. Wir beginnen mit der ersten Funktion, wobei der TDD -Zyklus des Hinzufügens eines Tests, den Pass, den Refaktor des Codes und wiederholt werden. Wir werden iterativ in kleinen Schritten arbeiten.

Die erste Funktion ist Folgendes:

---

1. Fügen Sie Spieler hinzu

Als Spieler möchte ich mich dem Spiel hinzufügen, damit ich spielen kann.

Szenarien:

1. Spieler hinzufügen

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. Duplizierter Spieler

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

Sie werden den ersten Test schreiben, und dann werde ich Ihnen Feedback zu seiner Qualität geben. Wenn der Test für mich in Ordnung ist, werden wir den Anwendungscode implementieren, den wir den Test erstellen. Dann werden wir nach Gelegenheit suchen, den Code klarer zu machen und es leichter zu verstehen, indem Sie ihn neu aufstellen.

---

Zusammen mit dem Code finden Sie die Eingabeaufforderungen, die ich verwendet habe, um die Paarprogrammiersitzung in den prompts > älter zu leiten. Ich habe für jeden neuen Schritt, den wir gemacht haben, eine neue Eingabeaufforderung -Datei erstellt. Ich habe weitere Eingabeaufforderungen in die gleiche Datei eingerichtet, die durch eine --- Zeile getrennt sind, wenn eine einzelne Eingabeaufforderung nicht dazu führte, dass alle Tests bestanden wurden.

Mein Feedback zur Ausführung dieser Kata mit Copilot

• Ich fühle mich weniger auf den resultierenden Code konzentriert, mehr auf die richtige Eingabeaufforderung und ob die Antwort "funktioniert" oder nicht
  • Ich bemerkte, dass ich mich manchmal mehr auf die Form der Eingabeaufforderung konzentriere und ob der Code kompiliert und die Tests immer noch bestehen als auf die Form des Codes ... manchmal führte uns dies zu einer Sackgasse, und wir mussten die Änderungen zurückversetzen und fangen Sie wieder an.
• Es ist nicht klar, wie empfindlich Copilot für das ist, was nach dem Refactoring besser zu tun ist: Refactor nach Belieben? Wann ist es sinnvoll, zum nächsten Test überzugehen?
• Oft sind die "Spezifikationen" von Natur aus mehrdeutig (was bedeutet das Spiel, dass das Würfel mit dieser Mehrdeutigkeit konfrontiert ist. Es ist sehr wahrscheinlich, dass die Antwort des Modells nicht die "Recht" ist, es sei denn in der Aufforderung uns selbst (so die Rolle der "Disambiguatoren", "Kunde" annehmen))
• Manchmal überraschen mich die Antworten des Modells (z. B. es schafft es, den Kontext gut zu verstehen und den Code zu ändern, um den Stil und die Form des vorhandenen Codes zu respektieren). Manchmal macht es Fehler, die wie "Ablenkungsfehler" erscheinen, wie wir Menschen tun?
• Copilot hat ein ausgezeichnetes Kontextfenster, es kann sich an Dinge erinnern, die einige Eingabeaufforderungen zuvor gesagt haben.
• Wenn es Refaktoren oder Änderungen vorschlägt, wird nicht klar, dass es auch die Tests beheben muss ... es konzentriert sich fast immer nur auf den Anwendungscode?
• Wenn der Code vorbereitete Refactoring benötigt, um die nächste Funktion zu berücksichtigen (die klassische „zuerst, die Änderung machen, dann die einfache Änderung vorzunehmen“), kämpft Copilot -Kämpfe:
  • Es scheint nicht in der Lage zu sein, sich dieser Art von Argumentation zu stellen (wie in „Wir müssen einen Schritt zurücktreten und die Dinge strategisch überprüfen“)).
  • Es kann nicht "komplexe" Gerüche identifiziert werden, wenn die Logik, die wir für die nächste Funktion benötigen, über mehrere Klassen verstreut ist. Daher müssen wir einen Schritt zurücktreten, bevor wir vorwärts gehen.
  • Auch wenn Sie es sagen, sie sollen von vorne anfangen und den gesamten Code wegwerfen, der ab dem Test, der rot geblieben ist Dinge in kleinen Schritten “.

Siehe auch meine Überlegungen hier (Italienisch)