24.10.16 TIL 타워 디펜스 프로젝트 -완-

 

 

오늘 발표를 끝으로 또 하나의 프로젝트가 종료되었다.

 

 

 

담당 업무 부분을 정리해보았다.

 

 

타워 구매

• 상점의 구매 버튼을 통해 이벤트 시작

클라이언트에서 생성될 타워의 좌표와 버튼 번호를 #30 towerBuy (handler Id) 로 요청

서버에서는 버튼 번호 === 타워 종류 로 구분하여 해당하는 타워 정보를 redis에 저장된 metaData 에서 가져온다. 

 

그 후 서버에서 관리하는 user의 소지금을 가져와서 간단한 검증을 진행한다.

 

검증에 문제가 없다면, 타워의 data를 redis 에 push 한다.

저장되는 내용은 타워의 종류 = towerType, 타워 좌표 = position , 그리고 강화 횟수 (구매 시 0 ) 이다.

 

 

 

그 후 return 되는 정보는 아래와 같으며,

 

해당 데이터는 다시 클라이언트에게 동일한 handler Id = #30 towerBuy 로 'response' 이름으로 전송된다.

 

클라이언트는 받은 패킷의 내용으로 메세지 출력, 타워 구매, 표시 골드 갱신하는 함수를 실행하게 된다.

 

 

타워 메뉴

타워를 찾아서 실행된다.

• 타워를 클릭 할 때, 해당 마우스 좌표에 타워가 있다면 실행된다.

클릭 시, 해당 타워의 사거리를 원으로 표시하고 타워의 능력치 정보와 타워 강화, 타워 판매 버튼을 생성한다.

 

 

타워 판매

• 타워 메뉴에 있는 타워 판매 버튼을 통해 실행

로직 자체는 타워 구매와 유사하며, #31 towerSell 핸들러로 클릭한 타워의 좌표를 payload로 보낸다.

서버에서는 받은 타워의 좌표와 동일한 좌표를 갖는 데이터를 redis 에서 찾는것으로 검증을 진행하며,

같은 좌표의 데이터가 있을 시, 해당 데이터를 삭제하고 해당 타워 가격의 절반에 해당하는 금액을 소지금에 더한다.

이 후 정상적으로 return 이 반환되면 클라이언트는 해당 타워를 제거한다.

 

 

 

타워 강화

• 타워 메뉴에 있는 타워 강화 버튼을 통해 실행

타워 판매와 동일하게 좌표를 받아서 진행하며, 동일한 좌표의 데이터를 redis 에서 찾은 뒤 enhanceLevel 을 +1 한다.

클라이언트는 서버에서 받은 데이터로, 강화를 실행한다.

 

 

 

 

 

# 회고 

 

Keep

하루에 한번 회의 시간을 정해서 각자의 진행 상황과 그날 구현 목표에 대해 공유하는 것이 좋았습니다.

A 의 작업이 완료되어야 B의 코드를 테스트할 수 있는 환경일 때,

A의 작업이 완료될 때 까지 시간이 더 필요하다는 사실을 공유받으면,

B는 임시 더미 데이터(하드 코딩)으로 코드 테스트를 한다거나, 일단 다른 작업을 진행하는 등의 판단이 보다 수월했습니다.

추가로, 회의 시간이 아니더라도 초기에 합의된 방향으로의 구현이 어렵거나, 다른 아이디어가 생길 경우,

그때 그때 의견을 나눠서 방향을 정한것도 좋았습니다.

 

Problem

의견을 나눌 때, 코드 작성 전에 계획에 대한 이야기를 하면

듣는 입장에서는 어떤 내용의 코드인지 잘 이해하기가 힘들어지고,

코드를 작성하고 해당 코드에 대한 의견을 물으면,

불필요한 코드로 결론 날 경우, 작성했던 코드를 다시 롤백 해야하는 상황이 생겼습니다.

앞으로는,

자신의 코딩 계획을 좀 더 논리적으로 설명 한다던가 , 간단한 예시 코드 정도까지만 작성하여 의견을 교환하면

위와 같은 일을 방지할 수 있을 거라고 생각합니다.

 

Try

코드 PR 을 올리면 PR 코멘트 외에도, 코드 작성자가 직접 해당 코드를 리뷰하는 시간을 가졌습니다.

위 방법으로 어떤 코드가 PR 된 것인지 좀 더 명확하게 팀에 공유가 될 수 있었는데요,

아쉬운 점이 있다면 리뷰 자체의 규칙을 정한것은 아니었기 때문에

팀원 모두가 PR한 내용의 코드를 설명하고, 테스트 과정을 보여주고 , 결과까지 보여주는 것에 시간 소요가 꽤 있었습니다.

불필요한 시간이었다는 것은 절대 아니지만, 목표는 어디까지나 merge 결과 이상이 없어야하는 것이었기 때문에,

코드의 목적, 테스트 과정이 명확했다는 부분과, 그 결과 확인된 이상이 없다는 점 정도만 리뷰하고

자세한 코드 해석은 주석과 코멘트를 활용했다면 리뷰 시간을 좀 더 단축 할 수 있을 것 같다고 생각합니다.