내일배움캠프 TIL (240223)

 

• 오늘 배운 것

오늘은 팀 프로젝트 시작하는 날이다. 

 

백오피스 프로젝트라는 이름으로 시작하는 프로젝트였는데, 

두 가지 프로젝트 (1. 펫시터 프로젝트, 2. 음식 배달 서비스) 중에서 한가지를 골라서 

여러가지 기능을 개발하고 구현하는 과제였다.

 

우리 팀은 조금 덜 복잡할 것으로 예상된  펫시터 프로젝트를 골랐는데....

덜 복잡은 개뿔이. 엄청 머리아팠다.... 하루에만 머리 과부하가 정말 여러 번 왔다.

 

일단 SA를 작성하면서 ERD랑 API 명세서, 와이어프레임을 작성하는데,

ERD에서도 문제가 있었고, API명세서를 작성하면서도 풀리지 않는 문제가 있었다...

 

일단 그 중 가장 답을 알 수 없는 것들은 튜터님께 질문을 하러 두어번 갔는데, 거기서 얻은 답이다.

 

이게 첫번째 질의응답을 거치고 난 후 우리 조가 짠  ERD인데, 관계를 짜는 것이 정말 어려웠다.

 

의도는 이랬다.

일단 한명의 유저가 한번 예약을 할 때, 여러마리의 반려동물을 한번에 한 시터에게 예약할 수 있다.

그런데 반려동물 테이블에서도, 예약을 여러 번 할 수 있으니(같은 날은 아니겠지만)

결국 예약테이블과 반려동물 테이블의 관계가 N:M 같이 만들어지는데, 

그게 그다지 좋은 구조가 아니라고 해서, 매핑테이블을 따로 만든 것이다.

 

이 결과를 도출하기 위해 긴 회의와 튜터님과의 질의응답이 있었다.

팀원들이 모두 N:M관계에 익숙하지 않아서, 처음에는 N:M관계가 아니라고 생각했었다.

 

---

 

그리고, 예약의 상태(신청중/수락됨/거절/취소 등)에 대한 것도 애매했다. 

처음에는 Reservation의 Record에 거절된 예약내역이 남아있을 이유가 없다고 생각했다.

 

남아있어봤자, 거절된 기록이지만, 동일한 날짜에 받을 새로운 예약의 장애물이 될까 봐

수락하지 않을 예약에 대해서는, 거절 대신 시터가 예약을 직접 취소할 권한을 주려고 했었다...  

 

그런데 튜터님과 질의응답 끝에, 레코딩은 웬만하면 지우지 않는다는 말을 듣고,

결국 REJECTED라는 Status를 줘서 레코딩을 유지하기로 했다. 

 

이로써 에러처리할 조건이 조금 더 늘어났다...ㅎ

 

API명세서를 써봤다.꼼꼼히 생각해서 다 적은 것도 아닌데, 이미 너무 router가 많았다.

게다가 아직 덜 적은 것도 있다....;; 이것들을 하나하나 다 3계층 분리하고 테스트 코드 짤 생각하니... 참....^^

 

주말에 전체적인 구조를 좀 정리하고, 부족한 부분을 좀 보완할 수 있으면 모르겠는데,

내 기능 브랜치 구현하기도 급급하다...;; 주말안에 완성할 수 있을지도 잘 모르겠다....