3차 프로젝트 회고록

1.  프로젝트 소개

소극장 티켓팅 서비스

티켓을 구입 후 선착순으로 좌석을 선택하고 입장해야 하는 소극장 입장 티켓을 온라인에서 좌석을 선택하여 구매할 수 있는 서비스

 

2.  프로젝트 사용 기술

node js, mysql, expressjs

 

3. 내가 맡은 역할

 

백엔드 역할을 맡았다.

프론트 3명 백엔드 4명이서 진행

 

구현해 본 기능

 

(detail)

연극 상세정보 조회

연극에 상세 좌석 정보 조회

 

git hub 링크 : https://github.com/applepc24/50-3rd-ITcat-backend/tree/main

GitHub - applepc24/50-3rd-ITcat-backend

postman api 문서 링크 : https://documenter.getpostman.com/view/30331356/2s9YsFCZEg

 

4. 해결하기 어려웠던 부분

이번에도 DB 덕분에 고생을 많이 했다....

초기 시트 클래스가 있는 db

프로젝트의 초기 아이디어는 티켓 예매 사이트를 개발하는 것이었다. 그러나 3주의 기간 중 1주가 지난 뒤, 우리는 DB에서 큰 문제가 있음을 발견했다. 초기에는 공연, 뮤지컬, 전시, 콘서트 등 다양한 이벤트를 다루기 위해 장소, 등급에 따른 좌석위치 등을 통일하려고 했으나, 이는 서비스의 본질과는 거리가 먼 생각이었다.

프로젝트의 중간에서 백엔드와 프론트가 맞춰지면서 우리는 초기 시나리오와의 큰 간극을 깨달았습니다. 게다가, 이러한 방식은 이벤트 관리자의 역할을 무시하고, 특히 전시를 하는 장소에서는 좌석과 시트의 등급이 필요하지 않다는 점도 알게 되었다.

여기서 1차 멘붕

 

2차 멘붕은 우리가 설계한 DB가 필요한 모든 데이터를 추출하기에는 적합하지 않다는 것을 깨달았을 때 찾아왔다. 장소, 공연, 좌석, 시트, 등급, 날짜, 시간 등 모든 변수에 대한 데이터를 추출하기가 어려웠다.

그 결과, 팀은 긴 회의를 통해 두 가지 선택 사항을 고려했습니다. 첫 번째로는 DB를 수정하고 다시 초기 시나리오를 따라가는 것이었습니다. 그러나 시간 부족으로 이를 완수하기 어려운 판단이었습니다. 그래서 우리는 두 번째 선택인 시나리오 변경을 택했다.

시트의 클래스를 제거하고 티켓의 가격을 통일하는 새로운 방향으로 나아가기로 결정했습니다. 이를 통해 우리는 소극장 티켓팅 서비스로의 전환을 시도하고자 했다. 이 방향은 초기 아이디어에서 벗어나지만, 우리는 프로젝트를 시간 내에 완료할 수 있을 것으로 판단했다.

 

수정 후 erd이다.

 

5.  2차 프로젝트가 끝나고....

이 경험을 통해 우리는 프로젝트 초기에 더 신중한 DB 설계가 중요함을 깨달았다. 혹시 모를 상황에 대비하여 초기 계획을 유연하게 조정할 수 있는 능력도 필요하다는 교훈을 얻었다...
(아무리 소통을 해도 틀린 점이 조금씩 있다. 그냥 프론트옆에 붙어서 api를 짜야하나..?)

 

내가 3차 프로젝트에서 발전시키고 싶은 부분이었는데 한번 확인해 보자

 

쿼리 빌더 사용해보기

(데이터 베이스 계획 잘하자)

트랜잭션문 이해하고 사용해 보기

(데이터 베이스 계획 잘하자)

프론트와 소통 많이 하여 내가 주고받아야 할 데이터에 대해 생각하기

(소통 많이 더 해야 한다. 진행 틈틈이 서로의 생각이 동일하고 일치하는지 확인)

불안해하지 않고 주어진 상황과 문제해결에 집중하기

(불안해 하기는 했지만 문제해결에 집중했다. 이건 좀 발전한 것 같다.)

 

기업협업에서 발전시키고 싶은 점

 

기업협업 프로젝트에 대해 이해하고 팀원과 소통 진짜 많이 하기 

프로젝트에 있어서 코드 짜는 것이 먼저가 아님을 알기

자기 일 끝났다고 여유 부리지 않고 예외사항에 대해 항상 생각하기

aws, docker에 대해서 공부하기