WEB프로젝트_TEAM_DREAM🧱

이번 프로젝트에서는 처음 시도해보는 것들이 조금 있어 걱정이 많았습니다. 하지만 프로젝트 기간동안 실제로 구현을 하고 작동하는 코드를 보며 첫 시도에 대해 앞으로는 좀더 긍정적인 태도를 갖게되는 계기가 되었습니다.

 

 

 

 

TEAM_DREAM

 

 

 

 

 

 

TEAM_DERAM 프로젝트

경매 플랫폼(KREAM)을 모델링하여 진행한 두번째 프로젝트

 

 

 

프로젝트 기간

2023.04.20~2023.05.04

 

 

 

담당 API

그래프 데이터 API (체결된 주문을 시세파악 쉽게 하기위해 시각적인 정보로 나타내기 위함)

bid info API (해당제품의 입찰, 낙찰데이터 가져와 판매자또는 구매자가 앞으로의 시세에 대하여 생각할수 있게함)

like API (관심상품 추가/삭제 기능) 

like list API (관심상품 리스트 즉시구매가와 함께 보여줌)

review create API (s3를 이용하여 사진리뷰도 가능하게 함)

address API (주소 저장API, 주소 리스트 가져오는 API) 

buyingPayment API (biddingbuy에 addressId 등록, deal status 상태 결제로 변경)

bidStatusScheduler API (입찰기간이 끝난 주문은 유찰로 변경하는 스케줄러)

 

 

이번 프로젝트를 하면서 유난히 github branch에 fix가 많이 있었다. 

기억에 남는 fix/branch는 node schedule를 이용하여 bidStatusSchedulerAPI에 관한 fix/branch입니다.

작성한 bidStatusSchedulerAPI가 실행되어 목데이터가 잘 바뀌는 것만 보고 merge를 했는데 다른 API를 작성할 때 bidStatusSchedulerAPI에서 에러가 나서 너무 당황스러웠지만 바로 fix/branch를 만들었습니다. 팀원분들께 양해를 구하고 git pull을 딜레이 부탁을 드렸습니다. 

작성한 코드를 다시 보니 유찰될 리스트가 없으면 에러가 생길수 밖에 없는 코드였습니다. 그래도 금방 문제되는 부분을 찾아서 다행이였습니다. 

node schedule

 

POSTMAN

https://documenter.getpostman.com/view/26858291/2s93eWzskR

 

ERD

 

Keep

스케줄러 생각했을때였던거 같았다. 경매 플랫폼이다보니 입찰상태와 입찰과정을 생각하면서 ERD를 구상하면서 그럼 입찰기간이 끝난 주문은 어떻게 구분해야하지라는 생각으로 처음에는 생각하지 못했던 스케줄러API까지 백로그에 넣을 수 있었습니다.

문제를 만난다면 해결하려고 매달리다가 약간의 휴식도 필요한것같습니다.

그래프관련 API에서 데이터를 가져오는 로직을 구현할때 였습니다. 처음에는 쿼리문에서 날짜와 거래가를 서로다른 배열로 꺼내오려 시도하였습니다. 2시간정도 데이터를 가져올 때 바로 원하는 데이터의 타입으로 가져오려 여러 방면으로 고민을 하고 시도하였지만 쉽지 않은일이였습니다. 결국 배열의 해당데이터가 아닌 다른 조건으로는 정렬이 안된다는 것을 알았습니다. 머리를 잠시 쉬면서 생각해보니 굳이 데이터를 DB에서 꺼낼때 가공을 하지않더라도 꺼낸후 원하는 데이터 구조를 만들어 주면 된다는 사실을 깨닫게 되었습니다. 그래서 날짜로 주문을 정렬하여 DB에서 데이터를 가져와 이후 날짜 배열과 가격배열을 각각 인덱스에 맞게 만들어 줄수 있었습니다.

 

 

Problem 

API를 짤때 고려하지 못했던 부분들이 실제 데이터를 넣다보니 에러가 많이 생겼었다. API를 Postman으로 여러차례 체크하였었지만 목데이터로 체크할수 없었던 부분의 함정이였던거같다.

스케줄러 처음 사용하다보니 잘 돌아가는거에만 집중해서 좀더 깊게 생각하지 못했던것...

unitTest를 프로젝트를 시작할때 BE팀원들은 각자 처음 맡은 API에 대해 구현을 하였습니다. 프로젝트의 시간이 짧고 unitTest를 진행하는데 데이터의 충돌문제와 unitTest를 구현하는데 시간이 너무 걸려서 중간부터는 구현을 멈췄다.

 

 

Try 

미리 어느정도의 실제와 비슷한 충분한 데이터를 넣어주면서 test하는것이 좋을것같다. 

-> API이 돌아가는 확인과 함께 여러데이터를 넣고 확인하기

unitTest 공부 하기

 

 

경매로직 이해와 설명 시간이였다

 

team_dream의 프로젝트를 진행하면서 1차때보다는 FE와 BE의 의사소통이 훨신 자연스러워졌다. 또한 데이터를 가져오면서도 프론트가 쉽게 값을 받는 것을 우선 고려하여 구현하였기 때문에 통신을 하면서 좀더 수월했다. 생각한대로 경매의 로직이 복잡하였던거 같았다. 팀원들이 소셜로그인과 s3, 스케줄러, 한 API클래스화등 처음 경험한것들이 많았지만 프로젝트기간 안에 잘 진행이 되었습니다. 생각지 못한 에러가 종종 났지만 옆에서 저의 멘탈을 관리해주신 다희님께 감사했습니다. 처음 시도할 것들이 많아서 걱정으로 시작했던 프로젝트였습니다. 걱정이 괜찮아지면 에러로 당황스러워졌던 개인적으로는 다이나믹한 프로젝트기간이였습니다. 시도하는 것에 대한 두려움은 어느순간 재미로 변하는 좋은 경험을 했던 이번 프로젝트였습니다. 물론 앞으로도 처음 마주하는것이 많을 텐데 사실 걱정은 버릴수 없겠지만 이번 프로젝트를 계기로 처음에 대한 기대를 조금이나마 할수 있을 것 같습니다.  

 

 

 

GitHub - minseoya/Dream-backend: 박세익, 장다희, 김민서, 송석준

https://github.com/minseoya/Dream-backend