6월 7일 화요일 ~ 6월 22일 수요일까지 약 2주간 데브코스 중간 팀 프로젝트를 진행했습니다
간략한 프로젝트 소개와 담당 개발 파트를 언급하고, 다음엔 이렇게 해야겠다 싶은 부분들을 정리하겠습니다
프로젝트 소개
GAMEBU는 게임을 같이할 파티를 구하는 종합 SNS 사이트입니다
위 링크는 모바일에 특화되어 있습니다
기존의 게임 커뮤니티와 다른점은 종합 게임을 지향한다는 점과 메시지 기능입니다
롤 듀오 구합니다
한 게임을 같이할 사람을 구할 경우 그 게임 커뮤니티만을 방문하면 됩니다
하지만 이 게임도 했다가 저 게임도 하고 싶다면, 여러 사이트를 방문하게 됩니다
이런 점이 불편하게 느껴졌고, 한 사이트에서 종합적으로 게임 파티 매칭을 지원하고자 개발하게 되었습니다
또한 게임 유저를 구할 때 보통 게시글과 댓글로 소통하게 되는데, 데브코스에서 제공한 API에 DM 관련 API가 있어서 꼭 도입해보고 싶다고 생각했습니다
맡은 파트
개발 파트는 페이지 단위로 나누었습니다
초기의 eslint, context api 셋팅
로그인 / 회원가입 페이지
개인 프로필 페이지
메시지 페이지
를 담당했습니다
아쉬운 점
브랜치 관련
브랜치 전략을 지키지 못했습니다
마감 시간이 다가오는데 파악하지 못한 에러 수정 사항이 많았습니다
A 브랜치에서 이 내용을 고치니 B 브랜치에서 다른 에러가 발생하는 경우도 있었고, 기존에 파악하지 못한 에러가 많았습니다
develop 브랜치에서 에러를 고치고, 부족한 내용을 보충하는 식으로 진행해서 브랜치 전략이 무너졌습니다
배포 이후의 브랜치 전략이 미흡했습니다
feature/login, feature/postDetailPage 등 페이지 단위로 브랜치를 나눠서 개발하고, develop으로 병합했습니다
배포할 때는 main을 배포하는건지, 다른 방법이 있을지에 대해서 아는 부분이 없어 release 브랜치를 두어 배포하였습니다
=>
추후 멘토님의 피드백을 통해 release/v1.0 같은 식으로 수정사항들을 기록하면서 배포하면 된다는 내용을 알게 되었습니다
리팩토링 내용에 해당 브랜치 전략을 반영해야겠습니다
컴포넌트 관련
컴포넌트의 구분과 재사용이 미흡했습니다
페이지로 작업하게 되면 컴포넌트가 크게 2개로 나뉩니다
여러 곳에서 사용하는 컴포넌트와 이 페이지에서만 사용하는 컴포넌트
한번만 사용하는 1회성 컴포넌트도 components 폴더에 저장하니 폴더가 복잡해졌습니다
=>
멘토님의 피드백으로 다른곳에서 사용하는 공통 컴포넌트는 components 폴더, login 페이지에서만 사용하는 컴포넌트는 pages/login 폴더 안에 저장하는 것으로 더 깔끔하게 폴더를 정리할 수 있을 것 같습니다
이렇게 하면 해당 컴포넌트가 어디서 사용될지도 추측할 수 있습니다
색상 관련
색을 활용하지 못했습니다
배경, 메인, 강조 3가지 색상을 임시로 흰, 회, 검으로 정하고 선 개발 진행 후 추후에 바꾸려고 했으나, 이미 익숙해져서인지 무난해서인지 다른 색상을 정하지 못했다
mui 관련
빠른 작업과 공통된 컴포넌트 사용을 위해 디자인 프레임워크를 사용했습니다
mui를 선택한 이유는 figma에 작업한 내용과 유사한 bottomNavbar가 이미 만들어져있기 때문에 선택했습니다
내장 theme 기능을 제대로 사용하지 못했습니다
theme 기능을 잘 이용하면 다크모드를 쉽게 구현할 수 있었을텐데 내장 기능을 제대로 활용하지 못한게 아쉽습니다
테두리 색이나 active일때 등 기본 파란색 커스텀 재사용이 미흡했습니다
mui는 className에 지정된 색을 바꾸는것으로 커스텀할 수 있습니다
이걸 공통 컴포넌트로 잡았으면 여러 곳에서 사용하는 button, input 등이 동일하고 간결한 코드를 작성할 수 있지 않았을까 하는 아쉬움이 남습니다
정리
컴포넌트를 어떻게 구분지을지가 항상 애매한 부분인 것 같습니다
추후에 개발을 진행할 때는 페이지 초안 figma를 참고로 하여
이 컴포넌트가 어떻게 구성되어야 하는지, 다른 곳에서 사용하는지 유무를 파악하고
사용한다면 components 폴더로, 아니라면 pages 내부 폴더에 정리하여
pages 폴더도 무엇을 렌더링하는지만 보여줄 수 있도록 해야겠습니다
