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掙扎：
  • 它似乎無法面對這種推理（例如，“我們需要退後一步，戰略性地審查事物”）
  • 它無法識別出“複雜”的氣味，就像我們需要的下一個功能所需的邏輯分散在多個類中一樣，因此我們需要退後一步。
  • 即使您告訴它是從頭開始的，從仍然是紅鍵的測試開始產生的所有代碼，即使您告訴它“讓我們嘗試一種新方法”或“讓我們去做，也通常都會重複相同的步驟事情以小步驟”。

另請參閱我的思考（意大利語）