goose game ai driven

Goose Game Kata ทำคู่กับ GitHub Copilot เพื่อฝึกฝนทักษะทางวิศวกรรมที่รวดเร็วของฉันและสะท้อนให้เห็นถึงรูปแบบการสื่อสารที่จะนำมาใช้เมื่อจับคู่กับเครื่องมือการเข้ารหัส AI-Assisted? ...

ทุกอย่างเริ่มต้นด้วยพรอมต์ต่อไปนี้:

ฉันต้องการทำการเข้ารหัส kata กับคุณเพื่อฝึกฝนร่วมกัน TDD, refactoring และการออกแบบซอฟต์แวร์ เราจะพยายามทำตาม TDD และขั้นตอนของมันค่อนข้างเคร่งครัด เรากำลังจะเขียนรหัส Kata ใน Kotlin โดยใช้การตั้งค่าโครงการอย่างง่ายใน Gradle kata มีดังต่อไปนี้: https://github.com/xpeppers/goose-game-kata เราจะเริ่มต้นด้วยคุณสมบัติแรกด้วยวัฏจักร TDD ของการเพิ่มการทดสอบทำให้มันผ่าน, refactor รหัสและทำซ้ำ เราจะทำงานเป็นขั้นตอนเล็ก ๆ ซ้ำ ๆ

คุณสมบัติแรกคือดังต่อไปนี้:

---

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 ที่ละเอียดอ่อนเป็นอย่างไรกับสิ่งที่ดีกว่าที่จะทำหลังจาก refactoring: Refactor at will? เมื่อไหร่ที่จะย้ายไปทดสอบครั้งต่อไป?
• บ่อยครั้งที่ "ข้อกำหนด" มีความคลุมเครือโดยเนื้อแท้ (เกมนี้เป็นอย่างไร "หมายถึงอะไร?) => ต้องเผชิญกับความกำกวมนี้เป็นไปได้มากที่การตอบสนองของโมเดลไม่ใช่" สิทธิ " ในการกระตุ้นตนเอง (ดังนั้นสมมติว่าบทบาทของ "disambiguators" ของ "ลูกค้า")
• บางครั้งการตอบสนองของโมเดลทำให้ฉันประหลาดใจ (เช่นมันสามารถเข้าใจบริบทได้ดีและปรับเปลี่ยนรหัสเพื่อเคารพสไตล์และรูปแบบของรหัสที่มีอยู่) บางครั้งมันทำให้เกิดข้อผิดพลาดที่ดูเหมือน "ข้อผิดพลาดที่ทำให้ไขว้เขว" เหมือนที่มนุษย์ทำ?
• Copilot มีหน้าต่างบริบทที่ยอดเยี่ยมสามารถจดจำสิ่งต่าง ๆ ที่กล่าวมาได้หลายครั้งก่อนหน้านี้
• เมื่อมัน refactors หรือเสนอการเปลี่ยนแปลงมันไม่ได้ตระหนักว่ามันยังจำเป็นต้องแก้ไขการทดสอบ ... มันมักจะมุ่งเน้นเฉพาะรหัสแอปพลิเคชันเท่านั้น?
• เมื่อรหัสต้องการการเตรียมการใหม่เพื่อรองรับคุณสมบัติต่อไป (คลาสสิก“ ก่อนอื่นทำให้การเปลี่ยนแปลงง่ายขึ้นจากนั้นทำการเปลี่ยนแปลงอย่างง่าย”) การต่อสู้ของ Copilot:
  • ดูเหมือนว่าจะไม่สามารถเผชิญกับการใช้เหตุผลแบบนี้ได้ (เช่นใน” เราต้องย้อนกลับไปและทบทวนสิ่งต่าง ๆ อย่างมีกลยุทธ์”)
  • มันล้มเหลวในการระบุกลิ่น "ซับซ้อน" เหมือนเมื่อตรรกะที่เราต้องการสำหรับคุณสมบัติต่อไปนั้นกระจัดกระจายไปทั่วหลายชั้นเรียนดังนั้นเราต้องก้าวถอยหลังก่อนที่จะก้าวไปข้างหน้า
  • แม้ว่าคุณจะบอกว่าจะเริ่มต้นจากศูนย์การทิ้งรหัสทั้งหมดที่ผลิตเริ่มต้นจากการทดสอบที่ยังคงเป็นแถบสีแดงมันมักจะทำซ้ำขั้นตอนเดียวกันแม้ว่าคุณจะบอกว่า "ลองวิธีการใหม่" หรือ "มาทำกัน สิ่งต่าง ๆ ในขั้นตอนเล็ก ๆ ”

ดูภาพสะท้อนของฉันที่นี่ (อิตาลี)