24.09.12 TIL : CH3 아이템 시뮬레이터

 

 

늘 그래왔듯이,

과제 제출하는 날이 되면 미처 발견하지 못했던 오작동 코드나, 오류들이 발견된다.

 

발견되는건지 발생하는건지 모르겠다

 

 

 

1. 아이템 판매시 장착된 아이템이 inventoryNumber 가 제일 낮은 경우, 그대로 팔려버린다.

 

이는, 대상 item을 find 하는 과정에서 equippedItem 의 여부를 묻지 않고 조회했기 때문이다. 

으음... 기초적인걸 놓쳤다.

이렇게 뜬금없이 장착된채로 아이템이 팔려버리면,

장착 해제+판매금획득+ 장착했던 능력치는 유지 라는 대환장 사태가 벌어진다.

 

어디까지나 개인 과제이기 때문에 찾는다면 고치면 되지만,

실제 서비스중인 게임이었다면 정말 끔찍하다.

 

조회시, where문에 equippedItem : false 로, 장착중이지 않은 아이템만 조회하게 하면 해결!

 

 

 

2. 해당 캐릭터의 가장 낮은 inventoryNumber를 탐색하는 과정에 문제가 발견됐는데, 

 

 

광분하여 작성한 Rawquery 부분에 오점이 있었다.

 

마음을 가다듬고...

 

무아지경으로 작성한 이 코드를 재 해석 해보면,

우선 findTargetItem 은 단순하게,

inventory 테이블에서 대상이 된 characterId 가 가진 아이템 중, inventoryNumber가 가장 작은 아이템

한 개를 조회한다.

 

조회 결과가 없을경우, 해당 캐릭터는 아이템을 한개도 보유하고 있지 않은 상태인 것이기에

해당 케이스는 따로 inventoryNumber 1을 부여하게 된다.

 

조회 결과가 있을 경우, 가능한 낮은 inventoryNumber  를 부여받기 위해 탐색을 진행하는데

이 부분이 로우쿼리 부분에 해당하며,

쿼리를 해석하면, 

inventory 테이블에서, inventory_number 가 가장 작은 결과 하나를 조회한다. 

그런데, 캐릭터 id가 대상이 된 캐릭터 Id 인것중에서만, 게다가  inventory_number 값에 +1 을 더해서 검색한다.

그 캐릭터 현재 가지고 있는 itemNumber 를 제외하고 

 

 

쉽게 말하면, 

그 캐릭터가 보유중인 아이템 중에서 가장 낮은 inventoryNumber 에서 +1 했을 때 값이 비어있는 값을 찾는다.

 

굉장히 본래 의도와 맞지만 함정이 있다.

탐색 자체를 현재 보유중인 값 부터 시작한다는 말이다.

 

이 말은, 해당 캐릭터가 보유한 itemNumber 의 최소값이 5 라면, 

1~4 가 비어있음에도 불구하고 5부터 탐색을 시작하게 된다.

 

 

만약 인벤토리 사이즈가 10 일 때, 

해당 캐릭터가 itemNumber 10인 아이템 한개만 들고 있다면,

해당 캐릭터는 더 이상 아이템을 획득할 수 없는 상태가 된다.

10부터 탐색하기 때문에 결과가 11이 되기 때문이다.

 

우연히 찾아낸 오류 이지만, 해결 방법은 간단했다.

 

아이템을 보유하고 있지 않을때는 1을 부여했던 것 처럼,

1을 보유하고 있지 않은 경우는 1을 부여하면 된다.

 

 

정말, 너무 만들고 싶어서 만들었지만

왠지 쓸데 없는 코드인것 같고...

로우쿼리 라고는 해도, 탐색 과정이 효율적이지 않은듯 한 데다가,

필수 구현 사항들과는 거리가 먼 코드라서 마음이 아프다...

 

또르르

 

 

아무튼 ..! 추가적으로 위에 있는 내용 처럼, 이전에 만들어놓은 캐릭터의 inventorySize 컬럼을 이용해서 

인벤토리의 한계를 적용해 보았다. 

 

전체 app 상에서, 아이템이 inventory로 추가되는 경우는 

해당 아이템 구매 API가 유일하기 때문에 여기저기 사용되어야 할 일은 없다.

 

 

그 후에, 

알고리즘 코드카타 -> 스탠다드반 강의  콤보로 인해서 과제 제출 마감이 임박하게 되었고,

 

많이 아쉽고 많이 부족한 채로 결과물을 제출하게 되었다.

 

 

부랴부랴 만든 API 명세서

 

 

 

아쉬운 점과 부족한 점

과정의 문제

 

우선, 해당 과제가 발제됐을 때 미처 듣지 못한 강의가 남아있었기 때문에

시작 과정 부터가 험난했다. 꽤 많은 분량의 강의가 남아있었고

과제는 이미 발제가 되었고...

 

빨리 과제를 시작하고 싶다는 기대,

내가 이번 과제를 잘 할 수 있을까? 하는 불안감,

강의 내용은 머리에 잘 들어오지 않아 답답함,

 

오만가지 생각이 교차하며 과제 시작부터 삐그덕 거렸기 때문에, 

만족한 결과가 나오지 않은것은 당연한 지도 모른다.

 

결국 강의를 들으면서 동시에 과제를 진행하게 되었고,

해당 부분에서 학습효과와 집중력이 떨어질 수 밖에 없었다.

 

과제 기간에도

스탠다드반 수업(CS), 챌리지반 강의(복합), 알고리즘 코드카타 모두 평소처럼 병행되었기에

12시간이 짧다고 느껴졌으며,

실제로 과제 기간동안 오후9시에 학습을 마친 날이 없었다.

 

다음 과제부터는 필요한 강의 부분을 최대한 발제 전에 마치도록 시간을 분배하여

이번과 같은 일이 생기지 않도록 해야겠다.

 

부족한 점

이번 과제는 부족한 점이 너무나도 많다

 

처음 사용하는 데이터 베이스, 코드작성을 위한 ORM,

의 서버를 대여하는 AWS RDS

 

express 구성, node 구성,

의 서버를 대여하는 EC2,

 

미들웨어 함수, 오류에 대한 처리, 

인증과 인가.

 

전부 너무 생소한 개념이었고, 결과적으로 이해도, 완성도 모두 부족한 채, 과제를 제출하게 되었다.

 

하지만

이런 핑계는 소용이 없다는 것을 알고있다.

 

앞으로 배울 내용들도 항상 새롭고 전부 생소 할 것이다.

 

언젠가는 아예 다른 언어를 사용해야 할 수 도 있다.

 

물론, 아직 조급해 할 필요 까진 없다고 생각한다.

이제 겨우 본 과정 한 달이 지났을 뿐이다.

 

정말로, 열심히 하고 있다고 당당하게 말할 수 있기 때문에,

지금처럼 학습을 진행하되, 위와 같은 일이 일어나지 않도록 시간 분배를 잘 해야하며,

같은 문제가 반복되지 않기 위해서는 기본기를 꾸준히 단련해야겠다. 

 

 

주눅 들지 말자.

포기하지 말자.