goose game ai driven

Github Copilot과 쌍을 이루는 Goose Game Kata는 프롬프트 엔지니어링 기술을 연마하고 AI 지원 코딩 도구와 쌍을 이룰 때 채택 할 의사 소통 패턴을 반영합니까?

모두 다음 프롬프트로 시작했습니다.

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 하는 데 사용한 프롬프트를 찾을 수 있습니다. 우리가 만든 새로운 단계마다 새 프롬프트 파일을 만들었습니다. 단일 프롬프트가 모든 테스트가 통과되지 않은 경우 --- 줄로 분리 된 같은 파일에 더 많은 프롬프트를 넣었습니다.

Copilot과 함께이 kata를 수행하는 것에 대한 나의 피드백

• 결과 코드에 집중하지 않고 올바른 프롬프트와 응답이 "작동"여부에 더 집중하고 있다고 생각합니다.
  • 때때로 나는 프롬프트의 형태와 코드가 컴파일되고 테스트가 코드 형태가 아닌 여전히 통과하는지 여부에 더 집중한다는 것을 알았습니다. 때로는 우리를 막 다른 골목으로 이끌었습니다. 그리고 다시 시작하십시오.
• Refactoring : Refactor at Fill에 대한 더 나은 방법에 대해 얼마나 민감한 Colecilot이 얼마나 민감한지는 확실하지 않습니다. 다음 테스트로 넘어가는 것이 언제 의미가 있습니까?
• 종종 "사양"은 본질적으로 모호합니다 ( "게임이 주사위를 굴립니다"라는 의미는 무엇입니까?) =>이 모호성에 직면하여 모호함을 줄이지 않는 한 모델의 응답이 "오른쪽"이 아닐 가능성이 높습니다. 프롬프트에서 우리 자신 (따라서 "고객"의 "명확하지 않은"의 역할을 가정합니다).
• 때로는 모델의 반응이 저를 놀라게합니다 (예 : 컨텍스트를 잘 이해하고 기존 코드의 스타일과 형태를 존중하기 위해 코드를 수정합니다), 다른 경우에는 인간처럼 "산만 오류"처럼 보이는 실수가 있습니까?
• Copilot은 훌륭한 컨텍스트 창을 가지고 있으며, 이전에 몇 가지 프롬프트가 말한 것을 기억할 수 있습니다.
• 변경 사항을 리팩터링하거나 제안 할 때 테스트를 수정해야한다는 사실을 알지 못합니다. 거의 항상 애플리케이션 코드에만 초점을 맞추고 있습니까?
• 코드가 다음 기능을 수용하기 위해 준비 요금 리팩토링이 필요할 때 (클래식 한“먼저, 변화를 쉽게하고, 쉬운 변화를 만들어라”), Copilot은 다음과 같습니다.
  • 이런 종류의 추론에 직면 할 수없는 것 같습니다 (예 :“우리는 한 걸음 물러서서 전략적으로 물건을 검토해야합니다”).
  • 다음 기능에 필요한 논리가 여러 클래스에 흩어져있을 때와 같은 "복잡한"냄새를 식별하지 못하므로 앞으로 나아 가기 전에 한 걸음 물러나야합니다.
  • 처음부터 시작하라고 말하면, 레드 바르지 않은 테스트에서 시작하여 생성 된 모든 코드를 버리더라도,“새로운 접근법을 시도하자”또는“하자. 작은 단계로 물건”.

여기 내 반성 (이탈리아) 참조