개요
- 사용자의 스케쥴을 관리해주는 웹 서비스.
- 개인 스케쥴 관리뿐 아니라, 다양한 인원과 스케쥴 공유 가능.
- 채팅기능과 친구기능 그리고 지도기능을 함께 제공.
서비스
- 개인 혹은 다수가 공유 할 수 있는 스케쥴 관리 웹 서비스
정리 내용
- 파트 (캘린더)
- 트러블 슈팅
- 앞으로 진행 계획
파트 (캘린더)
본인은 캘린더파트를 맡게되었다.
1. 캘린더 API 명세서
2. 캘린더 Entity 설계
작업 전에 먼저 전체 요구사항을 정리하고 Api 명세서, Entity 설계를 진행하고 코드를 진행하니, 충돌 이슈도 적고 초반 작업이 수월했다.
요구된 백엔드 코드를 짜는건 어렵지 않았다. 코드가 정상적으로 작동하는지 확인하기위해 GPT를 통해 임시로 프론트를 만들어 실행했고 정상적으로 작동되는걸 확인했다.
트러블 슈팅
총 3게의 팀으로 구성되었고 그 중에서 캘린더 파트를 맡은 본인이 웹서비스의 메인기능이자 메인페이지를 만드는 샘이다. 그러므로 다른 파트들의 작업이 끝나면 연결까지해야한다.
로그인팀의 작업이 완료되었고, marge 받고 병합하는 과정에서 트러블발생.
구조를 보면 domain안에 작업을하기로 했는데, 작업을 하다보니 global의 내용들이 조금씩 수정되었고 겹치거나 다른 부분에 충돌이 났다.
핵심은 A팀과 B팀의 내용이 달라서 충돌이 난 것이다.
다행이도 본인의 팀에서 global의 구조와 코드를 건들지 않고 작업하여서 로그인팀의 코드를 받아 오류난 부분만 조금씩 고치면서 실행하다보니 실행이되었다.
프론트와 백엔드 파트를 브랜치로 나누고 합치는 과정에서 충돌 발생
우리는 총 3게의 파트팀이 각각 백엔드와 프론트 브랜치를 만들어 총 6게의 브랜치로 작업을 진행하였다.
초기에는 문제가 없었으나, 본인 팀 기준 결과를 확인하기 위해 프론트와 백엔드 브랜치를 merge 하는 상황에서 이슈가 발생했다.
첫째로, Next.js를 포함하여 프론트작업을 처음하기에 모든게 낯설었다.
두번째로, 백엔드와 다르게 초기 규칙을 정해놓지 않았다.
초기에 규칙만 잘 정해놓고 작업했어도 일어나지 않았을 충돌이 merge과정에서 많이 발생했다.
병합 후, 하나씩 오류를 검색을 해가며 수정했고 대부분 단순한 충돌 이슈였다. 그렇게 최종적으로 프론트왜 백엔드를 합쳤다.
앞으로 진행
지금까지 캘린더 프론트와 백엔드 파일구조를 하나로 묶었고,
로그인팀의 코드를 받아와서 Merge 해서 연결해줬다.
이제 캘린더 생성, 조회, 삭제, 수정시 로그인한 유저의 값을 받아서 정상적으로 프론트와 백엔드가 연결된 상태로 작업이 진행되는지 확인하고 실행이 안된다면 코드를 수정해야한다.
