심화프로젝트 진행하던 중
발생한 트러블 슈팅 정리
1. 테스트 위해 게임을 실행하던 중 tower구입 이벤트를 실행하면
인스턴스 안에 존재하는 메서드를 읽지 못하는 오류가 발생했다.
분명 클래스 내에 선언되었는데 왜 읽지 못할까 생각을 했고
이 부분이 문제인 것 같다.
placeNewTower함수내에 getRandomPositionNearPath라는 함수가
경로 근처에 좌표를 랜덤 생성하는 함수가 있는데
버튼 클릭하고 콜백함수 실행 시 함수 내부의 또 함수가 있는데
여기서 문제가 발생한 듯
찾아보니 this바인딩을 해줘야 내부 함수에서도 동작을 할 수 있다 해서
이렇게 바인딩을 추가하니까 동작이 되었다.
정확한 문제는 인스턴스 내에서 콜백함수 실행 시 this바인딩을 하지 않아
내부 함수가 동작하지 않았던 것이다.
2. redis에 타워 데이터를 저장하는 코드를 작성하던 중
index를 추가해 타워의 인덱스를 통해 타워를 특정하기 쉽게
구현하던 중 2개의 클라이언트가 index를 공유하는 이슈가 발생했다.
예를 들면 클라 1이 타워 2번 구입해서 index가 0,1인 타워 데이터가 저장이 되었고
클라 2가 2번 구입하면 또 별개로 0,1인 데이터가 저장이 되어야 하는데
2,3으로 저장이 되는 것이었다.
코드를 너무 날먹으로 작성하려고 해서 발생한 문제인데
해결방법은 tower클래스에 index를 this로 할당해서 각각 가지도록 변경했다
이전에 배웠던 시퀀스 구현방법을 참고해서 해당 함수 호출마다 index가 각각 따로
증가하도록 변경해서 index를 공유하는 문제를 해결했다.
3. 이건 진짜 트러블슈팅이라고 하기도 애매한데
towerResponsePacket전송 중 역직렬화까지 되는 것을 확인했고 클라이언트에게 전송 후
직렬화하면 payload가 undefined로 출력이 되는 이슈가 발생했다.
보통 undefined로 출력이 되면 payload가 패킷구조와 달라서 사라지는 건가 생각을 했는데
팀원분이 구현한 역직렬화 직렬화 함수가 만약 구조가 달랐다면 payload가 사라지는 게 아닌
진작에 에러를 던지도록 구현을 해주셨다. 근데 그럼 구조문제는 아니고 전송과정에서 일이 발생했나 싶어서
서버에서 보내기 전에 바이트배열 출력하고, 클라이언트에 도착한 바이트배열을 찍어봤는데
둘이 살짝 다르게 나왔다. 그래서 프로토버퍼구조 문제인 건가 싶어서 직렬화 -프로토버퍼구조 검증-역직렬화
이 사이에 코드를 하나하나 유심히 콘솔 찍고 찾아보았는데 자세히 보니 response패킷 구조에 단 하나
타워구입 purchaseTowerResponse의 단어가 단순히 오타가 발생해서 찾질 못하는 오류였다.
그래서 오타인 부분을 수정해 주니 정상적으로 동일한 배열이 들어오고 역직렬화까지 되게
해결하였다.