[카우치코딩] 팀프로젝트 2주차 회고

2주차때 진행한 내용 및 느낀점

완성된 피그마와 기능 명세서를 바탕으로 ERD를 설계하는 과제와 API 명세서를 작성하는 과제가 있었다

ERD는 개인 쇼핑몰 프로젝트 진행할때 한번 만들어봐서 걱적이 없었다

하지만 API 명세서는 직접 만들어본적이 없어서 걱정이 되었다

ERD를 작성하면서 어려웠던 부분은 양방향 관계인 테이블을 1:N 관계로 분리하는 것이 어려웠다

특히 회원이 스터디를 신청하는 경우 마이스터디에서 자신이 신청한 스터디 목록을 확인할 수 있어야 했다

또한 회원이 로그인에 성공한 경우 마이페이지에서 자신의 언어를 선택할 수 있게 만들어야 했다

특히 언어는 카테고리에 속해있었기 때문에 생각해야 하는 부분이 많았다

처음 설계했을때는 카테고리 테이블을 따로 분리하고 언어 테이블도 따로 분리했었다

언어가 카테고리 추가될때 마다 카테고리 PK 값을 FK로 가지는 설계를 생각했었다

그런데 카테고리를 자주 사용하는 곳이 화면상에서 전체 스터디를 조회하기 위한 경우 밖에 없었다

따라서 언어 테이블에 컬럼을 세개를 둬서 언어가 추가될때 카테고리명도 같이 입력하는 방향으로 테이블 구조를 수정했다

회원이 스터디를 신청하고 신청한 내역을 마이 스터디에서 확해야 하는 경우도 테이블을 설계하는데 어려움이 있었다

회원과 스터디 사이에 중간테이블을 뒀는데 여기에 각 테이블의 PK를 어떻게 연결시켜야 하는지 몰랐다

한명의 회원이 여러개의 스터디에 참여할 수 있고 하나의 스터디에 여러 회원이 있을수 있다는 가정부터 시작했다

스터디 참여자를 관리하는 테이블을 회원과 스터디 테이블 사이에 뒀다

회원 테이블의 PK 컬럼을 스터디_참여자 테이블이 fk로 갖고 있었고 해당 fk를 다시 스터디 테이블이 PK로 갖고 있도록 설계했었는데

설계가 잘못되 있다는 것을 깨달았다

왜냐하면 스터디 참여 회원 fk를 스터디 테이블이 PK로 갖게되면 스터디를 insert 하는 과정에서 문제가 생기고 회원이 어떤 스터디를 참여하고 있는지 알수 없게 되는 문제가 생긴다

따라서 회원 테이블의 PK 컬럼을 스터디 참여자 테이블의 fk 로 갖고 스터디 테이블의 PK 컬럼을 스터디 참여자 테이블의 fk로 갖도록 설계를 변경했다

회원과 언어 그리고 회원이 좋아하는 언어테이블 사이에 관계도 문제가 있었다

회원의 PK 컬럼을 회원이좋아하는 언어를 관리하는 테이블이 FK로 갖고 있었다

fk가 다시 언어 테이블의 PK 컬럼이 되는 구조였다

이 상황 역시 언어를 insert 할때 제대로 추가되지 않는 문제가 생길수 있고

또한 회원이 좋아하는 언어를 가져오지 못하는 구조여서 설계를 변경하였다

회원 테이블의 PK 컬럼이 회원이 좋아하는 언어 테이블의 FK 컬럼이 되고 언어 테이블의 PK 컬럼이 회원이 좋아하는 언어 테이블의 FK 컬럼이 되도록 설계를 변경하였다

PS 2주차 회고를 작성하지 않았다면 개발들어가기 전까지 테이블 설계가 잘못되 있는줄 몰랐을것이다

프론트엔드와 협업하면서 요구사항중 회원이 스터디를 참여신청 누른 날짜와 실제 스터디의 시작날짜가 다른 경우 진해예정 스터디로 분류되 있다고 현재날짜가 스터디 시작날짜와 일치하면 진행중 스터디로 분류되도록하는 요구사항이 있었다

처음에 해당 요구사항을 충족시키기 위해 생각한 방법은 회원이 마이 스터디 페이지를 조회할때 현재 날짜를 가져와서 스터디의 시작날짜와 비교하는 것을 생각했다

현재 날짜와 시작날짜가 다르면 진행예정 스터디로 분류하고 현재 날짜와 시작날짜가 같으면 진행중 스터디로 분류하는 것을 생각했다

그런데 스터디를 신청하고 마이 스터디에서 처음으로 조회하는 경우에는 스터디 신청날짜와 스터디 시작날짜를 비교하여 다른 경우 진행 예정 스터디로 분류할 수 있지만

조회하는 날짜가 바뀌면 스터디 신청날짜가 사용되기 어렵겠다는 생각을 했다

따라서 회원이 마이스터디를 조회하는 날짜를 자바 Date를 통해 가져와서 스터디의 시작날짜와 비교하는 방법을 생각해 보았다

그러면 진행예정 스터디 목록에 있는 스터디의 시작날짜와 이를 조회하는 시점의 현재 시간 정보를 가져오면 되므로 해결될수 있을 것 같았다

그런데 문제는 회원이 마이스터디 페이지에 들어가서 스터디를 조회를 해야 날짜가 비교된다는 것이였다

회원이 마이스터디 페이지에 들어가지 않아도 자동으로 날짜가 비교되어 진행중 스터디로 필터링 되있어야 했다

구글링을 해보았더니 실시간 으로 처리하기위해 소켓통신을 사용해야 하는 것을 알게되었다

핑계일수도 있지만 백엔드가 두명이었거나 프로젝트 기간이 조금 길었다면 소켓통신도 적용해보는 것을 생각했을것 같다

그런데 이번 팀프로젝트는 백을 혼자서 하게되었고 oauth도 신경써야 하고 JPA를 기반으로 엔티티를 설계하기 때문에 신경써야 할것이 많았다

따라서 고맙게도 프론트에서 현재날짜를 가져와서 스터디 시작날짜와 비교해서 진행중으로 바뀌는 경우 데이터를 전달해 주기로 했다

프론트에서 실시간으로 현재 시간 정보를 가져올수 있다고 했다

해당 프로젝트가 마무리된 후에 소켓통신을 공부해서 나도 적용해볼수 있도록 개선해 볼 예정이다

API문서를 작성하는 과제도 있었다

혼자서 개발할때는 erd도 내가 만들고 어떤 데이터가 필요한지도 직접 결정하면되니까 문제가 없었다

그런데 팀프로젝트는 백에서 받고 싶은 데이터가 있어도 프론트에서 줄수 없는 경우가 있었다

또한 각 기능별로 요청이 들어갈때 백 입장에서 생각한 요청 메서드와 프론트 입장에서 생각한 요청 메서드가 다른 경우도 있었다

이는 서로 데이터를 바라보는 관점이 달라서 생긴문제였다

이를 해결하기 위해 기능 명세서를 바탕으로 백 입장에서 필요한 데이터 와 어떤 요청에 어떤 메서드가 필요한지 먼저 작성했다

그후 프론트와 함께 해당 데이터를 줄수 있는지 비교했고 추가적으로 프론트에 응답해줘야 하는 데이터를 추가하거나 성공 응답코드만 내보내고 프론트에서 재요청하는 방향으로 수정해 나갔다

API문서를 작성하면서 프론트와 백이 데이터를 보는 관점이 다르다는 것을 알게되었다

또한 프론트가 어떤 식으로 요청을 보내는지 어느정도 알고있어야 협업하기 편하다는 것도 알게되었다

따라서 팀프로젝트가 종료되면 프론트에 대한 공부도 해놔야 할것 같다

특히 알림이 실시간으로 쌓이게 해달라는 요구사항이 있었다

해당 요구사항에 대해 프론트와 백이 이해하는 방향이 서로 달랐다

프론트에서는 회원이 스터디를 신청했을때 상태가 진행예정이라면 스터디가 진행중으로 바뀌면 알림이 두개가 쌓이는 것으로 이해를 하고 있었다

백의 경우 스터디를 신청했을때 상태가 진행중 상태로 바뀌게 되면 기존에 발생되었던 알림의 메시지 내용만 수정되는 것으로 이해를 하고 있었다

서로 요구사항에 대한 이해가 달랐다

이를 해결하기 위해 프론트에서 설명한 요구사항을 충족시킬수 있는 방법을 먼저 생각해 보았다

처음에는 알람 테이블과 스터디에 참여하는 회원 테이블 사이에 관계테이블을 둬서 날짜를 기준으로 스터디 상태가 바뀌는 경우 알람테이블에 새로운 알람을 만들어 추가해주는 방식을 생각했었다

그런데 목요일 멘토링에서 스터디 리더가 스터디 신청자를 신청시킬지 말지 결정하는 권한이 현재 프로젝트에 없기에 알림 기능이 필수 적으로 필요한지를 여쭤보셨다

즉 , 현재 기획은 스터디 신청하기 버튼을 클릭하면 스터디가 무조건 신청되는 방식이기에 알림 기능이 필요하지 않다는 말씀을 해주셨다

결론적으로 알람 기능은 제외하기로 했다

대신 프론트에서 진행예정 스터디의 경우 실시간 날짜를 기준으로 스터디 시작날짜가 몇일 남았는지 비교하여 D-day 형식으로 표시해 주는 방향으로 알람 기능을 대체하기로 했다

목요일 멘토링 말미에 백엔드 프론트엔드 멘토와 인사하는 시간을 가졌다

백엔드 멘토분이 미리 짜오신 일정표를 봤는데 일정이 빡세겠다는 생각을 했다

물론 백엔드 혼자여서 그런것도 있을것이라고 생각한다

한편으로는 프론트가 두명인것이 부러웠다

또 한편으로는 직접 다 하니까 많이 배우고 성장할 수 있겠다는 생각도 했다

어느쪽이든 이미 시작된것이니까 열심히 해야 겠다

백엔드 멘토님으로부터 첫 과제를 부여 받았다

헤로쿠 서버에 가입하고 프로젝트를 생성하는 과제였다

헤러쿠는 처음들어봐서 구글링을 통해 무료로 클라우드 환경에 서버를 설치할수 있는 클라우드 플랫폼 이라고 한다

멘토님께서 헤로쿠 서버에 디비 서버를 설치해 주셨다

나는 디비 서버 정보를 바탕으로 POSTGresql을 설치하여 헤로쿠 서버와 연결하는 작업을 진행했다

또한 프로젝트를 생성하여 프로젝트와 DB서버를 연결하는 작업을 진행했다

첫 미팅때 멘토님께서는 모르는 것이 생기면 주저하지 말고 물어보라고 했지만 회사를 다니는 경험상 노력하지 않고 물어보는 것은 성장에 한계가 있기에 최대한 고민했다

헤로쿠 서버를 spring boot yml 설정파일을 통해 연결하는 작업에서 에러가 발생했다

구글링 결과 url을 작성하는 방식과 순서에 문제가 있어 스택오버플로우를 참고 하여 수정했다

프로젝트를 실행시키니 연결이 잘되었고 에러가 없어졌다

2주차는 많은 것을 해보면서 많은 생각을 하게 해준 시간이였다

왜 팀프로젝트가 필요하고 왜 해야하는지 직접 몸으로 깨달을수 있어 힘들었지만 재밌었다

다음주부터 개발을 시작하는데 열심히 삽질해서 좋은 결과물이 나왔으면 좋겠다

화이팅~!!