콘텐츠로 이동

여러 파일에 걸친 복잡한 문제 수정

이 모듈은 설정 지침에 따라 게임을 로컬로 이미 실행했다고 가정합니다.

이전 모듈에서 우리는:

이 두 작업은 모두 상당히 독립적이었습니다. 여러 파일에 걸쳐 있는 좀 더 복잡한 것을 시도해 봅시다.

1

문제 이해

게임 플레이어들은 때때로 "E" 프롬프트가 예상대로 작동하지 않는다고 보고합니다. 이것은 벽 근처에 서 있을 때 발생하는 것 같습니다:

alt !!alt

이 녹화에서 플레이어가 상자와 아이템에 충분히 가까이 있음에도 불구하고 "E" 프롬프트가 사라지는 것을 볼 수 있습니다.

Kiro에게 이 문제를 해결하도록 요청해 보세요. 예를 들면:

Sometimes when the player is closer to the wall than to an interactive object like an item or the chest, then the interact prompt does not appear over the interactive object.

2

제안된 솔루션에 대해 생각하기

Kiro는 문제를 올바르게 식별할 수 있어야 합니다. 플레이어에게 가장 가까운 객체를 찾는 함수가 벽을 필터링하지 않으므로 플레이어가 벽에 가까우면 벽이 실제로 상호작용하지 않더라도 벽을 가장 가까운 객체로 표시합니다.

alt !!alt

모델은 물리 질량이 Infinity인 객체를 제외하는 검사를 도입하여 버그를 수정하도록 제안했습니다. 이것은 단기적으로 문제를 해결하는 데 기술적으로 작동하지만 최선의 수정일까요? 유한한 질량을 가진 비상호작용 객체가 있으면 어떻게 될까요? 또는 Infinity 질량을 가지지만 여전히 상호작용하는 객체가 있으면 어떻게 될까요?

이 제안된 코드 솔루션은 의미론적 의미가 해당 로직과 직접 관련이 없는 속성에 의해 트리거되는 로직을 추가하고 있습니다. 이 수정은 일시적으로 작동하지만 오버로드된 동작은 나중에 확실히 중단되거나 미묘한 버그를 일으킬 것입니다.

AI를 사용할 때는 정신적으로 참여해야 합니다. 첫 번째 AI 제안을 맹목적으로 받아들이지 마세요. AI가 간과했을 수 있는 모범 사례와 더 간단한 솔루션에 대해 생각하세요.

3

프로젝트 전체에 걸친 리팩토링

이것을 game-object-system.ts 파일에 완전히 독립적으로 포함된 문제로 취급하는 대신 더 큰 리팩토링을 수행해 봅시다. 게임 객체가 생성되는 모든 곳에서 생성된 객체가 상호작용을 의도했는지 여부를 미리 표시해야 합니다.

다음과 같은 프롬프트를 시도해 보세요:

In #GameObject add a new required property `interactive`. In #updatePlayerProximity filter out non interactive objects All calls to #addObject throughout the code need to set interactive to true or false

#를 사용하여 컨텍스트 선택기를 불러오세요. 프롬프트에서 타입, 클래스, 함수 및 기타 코드 기본 요소를 참조하여 모델이 올바른 컨텍스트를 바로 볼 수 있도록 함으로써 결과의 정확성을 높일 수 있습니다.

결과는 다음과 유사해야 합니다:

alt !!alt

하나의 변경 대신 프로젝트의 많은 파일에 걸쳐 22개의 변경이 있습니다. 이 리팩토링은 게임 객체의 API가 객체가 상호작용을 의도했는지 여부를 표현하기 위한 적절한 의미론적 의미를 포함하도록 보장합니다.

LLM은 기능을 구현해야 할 때마다 앞으로 이 의미론적 의미를 활용할 수 있습니다.

이 모듈에서 세 가지 핵심 개념을 배웠습니다:

  1. 계속하기 전에 AI 생성 코드를 확인하세요. 코드가 오늘 제대로 작동할 수 있지만 LLM은 지금 당장 보고 있는 문제에 대해서만 생각하고 있으므로 몇 단계 앞을 생각해야 합니다.
  2. Kiro에서 프롬프트할 때 컨텍스트 선택기를 사용하여 코드의 특정 함수, 클래스 또는 타입을 언급하세요. 이것은 모델 컨텍스트를 향상시키고 더 정확한 결과를 생성합니다.
  3. 이름 지정은 중요합니다. 코드의 "API"가 정확한 의미론적 의미를 갖도록 하세요. 의미론적 의미와 직접 관련이 없는 여러 유형의 동작으로 속성을 오버로드하지 마세요.

다음 작업으로 넘어가봅시다:

Vibe 리팩토링은 vibe coding의 50%