goose game ai driven

与Github Copilot配对的鹅游戏Kata可以提高我的及时工程技巧，并反思与AI辅助编码工具配对时采用的通信模式？...

一切都从以下提示开始：

我想和您一起做一个编码Kata，一起练习TDD，重构和软件设计。我们将尝试严格遵循TDD及其步骤。我们将使用Gradle中的简单项目设置来对Kotlin的Kata进行编码。 Kata如下：https：//github.com/xpeppers/goose-game-kata。我们将从第一个功能开始，从添加测试的TDD周期，使其通过，重构代码并重复。我们会以小步骤进行迭代工作。

第一个功能是：

---

1。添加玩家

作为一名玩家，我想将我添加到游戏中，以便可以玩。

方案：

1. 添加播放器

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. 重复的播放器

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

您将编写第一个测试，然后我将为您提供有关其质量的反馈。如果测试对我来说是可以的，我们将继续实现我们将进行测试的应用程序代码。然后，我们将寻求任何机会，使代码更清晰，通过重构来易于理解。

---

与代码一起，您可以在prompts >较早的提示中找到我用来指导配对编程会话的提示。我为我们制定的每个新步骤创建了一个新的提示文件。当单个提示没有导致所有测试传递时，我将更多的提示放在同一文件中，并由a ---行分开。

我对用副驾驶表演这个kata的反馈

• 我觉得我不太专注于由此产生的代码，更专注于正确的提示以及响应是否“起作用”
  • 我注意到有时我会更多地关注提示的形式，以及代码编译和测试是否仍然通过而不是代码的形式……有时这导致了我们的终点，我们不得不重新恢复更改然后重新开始。
• 目前尚不清楚副驾驶对重构后更好地做什么：随意重构？进入下一个测试是什么时候有意义的？
• 通常，“规格”本质上是模棱两可的（“游戏”掷骰子的意思是什么？）=>面对这种歧义，模型的响应很可能不是“正确的”，除非我们减少歧义性的歧义在提示自己中
• 有时，模型的回答使我感到惊讶（例如，它设法很好地理解了上下文并修改代码以尊重现有代码的样式和形式），其他时候它会像我们人类一样，看起来像“分心错误”？
• Copilot有一个出色的上下文窗口，它可以记住以前说过的几个提示。
• 当它重构或提出更改时，它没有意识到它也需要修复测试……它几乎总是只关注应用程序代码？
• 当代码需要准备重构以适应下一个功能时（经典“首先，使更改变得容易，然后使更轻松的更改”），Copilot挣扎：
  • 它似乎无法面对这种推理（例如，“我们需要退后一步，战略性地审查事物”）
  • 它无法识别出“复杂”的气味，就像我们需要的下一个功能所需的逻辑分散在多个类中一样，因此我们需要退后一步。
  • 即使您告诉它是从头开始的，从仍然是红键的测试开始产生的所有代码，即使您告诉它“让我们尝试一种新方法”或“让我们去做，也通常都会重复相同的步骤事情以小步骤”。

另请参阅我的思考（意大利语）