[Fandom-K] 코드잇 스프린트 기초 프로젝트 회고

fandom-k

[목차]

• 시작하며...
• 프로젝트 선정 이유 및 목적
• 프로젝트 초기 세팅
• 컨벤션
• 깃허브
• 내가 구현한 기능
• 프로젝트 회고

 

시작하며...

코드잇 스프린트 6기 - 파트2 에서 기초 프로젝트를 진행하였다.

 

프로젝트 주제는 제공된 4가지 중에서 하나를 선택해서 약 2주 동안 진행하고 주어진 주제에서 기본 요구사항은 지키면서 그 외 디자인이나 추가적인 기능을 추가할 수도 있었다.

 

프로젝트를 끝난지 시간은 조금 지났지만 내가 어떤 걸 맡았고 어떻게 구현했는지 상기시키고 정리하기 위해 회고록을 작성하게 되었다.

 

프로젝트 선정 이유 및 목적

선정 이유

주제는 총 4가지가 있었으며 가장 난이도가 높은 프로젝트가 바로 Fandom-k 라는 프로젝트였다.

그래서 이왕 하는 김에 어려운 프로젝트를 하면 좋을 것 같고 다른 프로젝트와 비교해 보았을 때, 난이도 차이가 커 보이지 않았고 다른 프로젝트에도 캐러셀이나 탭 같은 기능이 있어 기능구현 면에서 비슷하다고 생각해 선정하게 되었다.

 

그리고 특히 Fandom-k 는 아이돌 조공 플랫폼 서비스인데 내가 아이돌을 좋아해서 해당 주제에 흥미로웠다.

(실제로 지금까지 아이돌 콘서트, 팬미팅 15번 이상 가볼 정도로 좋아함 ㅎㅎㅎㅎ...)

 

목적

프로젝트를 진행함으로 팀의 협업 능력과 배웠던 내용을 바탕으로 프로젝트 구현 능력을 쌓는 것이 목적이었다.

 

프로젝트 초기 세팅

프로젝트 진행 사항을 정리하고 문서로 기록하기 위해 노션을 활용했다.

 

사용 언어

React, Javascript, scss module 을 사용하였다.

 

이번 프로젝트에서 처음으로 scss module 을 사용하였는데, 모듈화 된 css 를 사용하니 컴포넌트별로 캡슐화하여 다른 컴포넌트와의 충돌을 방지할 수 있어 네이밍도 간편했다. 그리고 scss 의 변수, 믹스인 사용하게 되어 편리했다.

 

scss 사용예시 - mixin, 변수

 

라이브러리

• react-router-dom : 페이지 라우팅
• axios : 데이터 패칭
• eslint + prettier : 코드 포맷팅
• classnames : 동적 className
• framer-motion : 애니메이션
• react-toasitiy : 토스트 창
• react-slick : 캐러셀

 

이렇게 사용하였다.

 

scss 로 어떻게 동적으로 스타일을 적용하면 좋을지 고민을 하다가 classnames 라이브러리를 알게되어 이를 사용하자고 제안하였다. 그래서 아래 코드처럼 조건부로 className 을 손쉽게 적용할 수 있어 코드가 짧아지고 가독성도 좋아져서 유용했다!

classnames 라이브러리 사용

다른 팀원분도 만족하셨다 👍

classnames 라이브러리 굿

 

컨벤션

팀 프로젝트를 하면서 중요한 게 바로 컨벤션이다. 그래야 코드의 일관성이 있고 가독성 향상, 유지보수성에 좋기 때문이다.

내가 팀 프로젝트 경험이 있다 보니 적극적으로 내가 그동안 사용했던 컨벤션을 추천하였다.

 

코드 컨벤션

eslint + prettier 를 사용하였고 eslint 는 airbnb 규칙을 사용하되 너무 빡빡한 규칙은 껐고, import 구문 정렬도 규칙으로 설정하여 코드의 일관성을 지키도록 노력했다. prettier 는 아래 코드로 설정했다.

prettier

 

커밋 컨벤션

커밋을 할 땐 gitmoji 를 사용하여 무슨 기능을 구현했는지 한눈에 보기 쉽게 하였다.

커밋 컨벤션 (노션 캡쳐함)

 

브랜치 전략

브랜치 전략은 다음과 같이 했다. 기능별로 브랜치를 나누니 리뷰할 내용이 적어지고 main 에 merge 할 때 충돌도 적었다.

브랜치 전략

기타 전략

나는 폴더를 만들고 index.jsx 이렇게 하는 걸 선호하는데 다른 팀원분도 이 방식을 선호한다고 하여 채택하게 되었다.

그 밖에도 svg, 절대경로, css reset, 화살표 함수 사용 등등 규칙을 정했다.

파일 컨벤션, 폴더 구조, svg

 

프로젝트랑 팀이 끝났음에도 다른 팀원이 위에 폴더 구조가 마음에 들었다고 한다 뿌듯

폴더 구조

 

깃허브

이슈

이슈 탬플릿은 왼쪽처럼 만들었고, 오른쪽처럼 사용하였다.

이슈

약 2주동안 나는 24개의 이슈를 생성했다. (하루에 한 개 이상 기능 구현한 듯..)

24개

 

풀 리퀘스트

작업이 끝나면 Pull Request 를 올렸고 템플릿 또한 내가 적용했고 오른쪽처럼 자세하게 내용을 적었다.

PR

 

팀원들끼리 리뷰를 활발하게 달고 적극적으로 피드백을 달면서 소통을 했다. 👍

 

내가 맡은 부분도 열심히 하는 것도 중요하지만 다른 사람 코드를 이해하면서 어떻게 구현했는지 보면서 좋은 점 아쉬운 점을 찾아 같이 성장해 나갈 수 있기 때문에 팀 프로젝트에서 리뷰가 정말 중요하다!

 

리뷰1

리뷰2

 

그리고 merge 방식은 squash&merge 방식을 사용하여 main 에 깔끔하게 merge 되도록 하였다.

squash & merge

 

내가 구현한 기능

이제 가장 중요한 내가 구현한 기능이다. 먼저 우리 팀은 공통 컴포넌트 구현 -> UI 구현 -> API 구현 이러한 플로우로 진행하였다.

 

프로젝트 초기 세팅하기

위에서 말한 프로젝트 초기 세팅과 규칙 및 구조를 적용하였다.

 

초기세팅

 

공통 컴포넌트 만들기

나는 캐러셀 컴포넌트 만들기로 하였고, 시간 단축을 위해 react-slick 이라는 라이브러리를 사용했다. 그리고 시간이 남아 프로필 사진 컴포넌트도 만들었다. 

 

그리고 Javascript 환경에서 공통 컴포넌트를 다른 사람도 쉽게 사용하기 위해 propTypes 를 설정하고 컴포넌트 위에 주석도 달았다. 그러면 오른쪽 사진처럼 컴포넌트에 hover 를 하면 해당 컴포넌트 props 에 대한 설명이 보이게 된다.

(주석은 내 아이디어, propTypes 은 다른 팀원 아이디어)

propTypes, 주석

 

GitHub Action 코드 작성

프로젝트가 Organization 이라 개인 레포지토리에 fork 한 후 main 에 Push 될 때마다 계속 개인 레포지토리에 가서 sync 맞춰야 하는 번거로움이 있어 자동 배포 기능을 깃허브 액션 코드로 작성했다.

 

추가적으로 리뷰를 할 때, 다른 사람의 코드가 잘 실행되는지 확인하기 위해 직접 로컬에서 브랜치로 이동한 후 실행해 확인하는 과정이 번거로워 미리보기 배포 기능도 깃허브 액션 코드로 작성하여 구현하였다.

 

이에 대한 자세한 내용을 블로그에 작성하였다.

[pull request vercel 미리보기]

[Github Action] Organization 레포지토리 vercel 미리보기 preview 배포

[vercel 자동 배포]

[Github Action] 깃허브 Organization 레포지토리 vercel 자동 배포

 

후원을 기다리는 조공, 내 크레딧 UI 구현

후원을 기다리는 조공 UI 구현은 API 를 연결하기 전이라 mock 데이터를 사용하였다. 그리고 그 위에 있는 내 크레딧 UI 도 구현하였다.

 

내 크레딧, 후원을 기다리는 조공

 

후원을 기다리는 조공 API 구현

후원을 기다리는 조공 API 구현은 먼저 엔드 포인트를 환경변수로 등록하였다. 

그리고 GET 요청을 하는 커스텀 hook 은 팀원분이 만들어주셔서 그걸 사용했고, 추가적으로 로딩에러 컴포넌트를 만들었다.

 

API 구현

로딩에러 컴포넌트

 

NotFound 페이지, 애니메이션, 모달 Portal 리팩토링

내가 맡은 부분 구현이 끝나 새로고침 할 때마다 사진이 바뀌는 NotFound 페이지를 만들었고,

다른 팀원분이 만든 모달 컴포넌트가 z-index 999 인데도 캐러셀 뒤에 배치되는 현상을 발견하여 Portal 로 리팩토링 하였다.

 

not found 페이지

 

추가적으로 Framer-motion 라이브러리를 사용하여 버튼, 모달, 탭, 페이지 전환, 스크롤 애니메이션을 구현하였다.

이에 대한 자세한 내용은 블로그 글에 작성하였다.

[famer-motion 애니메이션 적용]

[React] Framer motion 애니메이션 적용 - 버튼, 모달, 스크롤, 화면전환

 

크레딧 충전, 후원, 이달의 아이돌 모달 구현

원래 이 부분은 다른 팀원이 하기로 했는데 코로나에 걸리시고 연락이 되질 않아 내가 UI 및 기능과 API 기능을 구현하게 되었다.

 

크레딧을 관리하는 부분은 API 가 아니라 로컬스토리지에 저장하는 건데 크레딧이 바뀌어도 다른 컴포넌트에 업데이트가 되지 않아 Context API 를 사용하여 전역에서 관리할 수 있도록 하였다.

크레딧 충전하기

후원하기에서 크레딧을 입력하는 부분은 util 함수를 만들어 숫자가 아닌 다른 문자를 입력하면 자동으로 0이 입력되도록 하였다.

후원하기

스크롤도 직접 커스텀 하였다.

이달의 00 아이돌

그리고 모달의 버튼을 눌러 기능을 수행하고 해당 기능을 수행했다는 시각적인 UI 가 필요한 거 같아 react-toastify 라이브러리를 사용해서 토스트 창을 구현하였다.

토스트1

토스트2

 

발표

마감기한까지 프로젝트가 잘 마무리 되었고 발표 전날 발표 자료를 제작하였다. 나까지 총 3명이 만들었고 발표는 내가 맡았다.

발표 자료

발표 대본

 

프로젝트 회고

처음부터 컨벤션을 잘 작성하고 규칙을 잘 정해 프로젝트가 순조롭게 잘 진행된 것 같다. 사실 옛날에 진행했던 프로젝트는 기능별로 브랜치를 분리하지 않고 사람 이름 별로 분리했더니 충돌이 많이 발생하였고, 공통 컴포넌트를 만들지 않아서 겹치는 코드가 많이 발생했던 경험이 있었다. 

 

그리고 코드 리뷰와 피드백이 활발하여 다른 팀원이 작성한 코드에서 개선점을 찾는 과정에서 비판적인 사고력이 향상되고, 코드 리뷰를 바탕으로 코딩 스킬 능력을 배워 내 코드의 품질도 개선시킬 수 있게 되었다.

 

또한 기능을 구현하면서 단순히 주어진 기능만 구현하는 게 아니라, 추가적으로 필요해 보이는 기능과 있으면 좋을 거 같은 기능을 계속 탐색하여 프로젝트의 전체적인 품질과 사용자 경험을 향상시킬 수 있도록 노력하였다.

 

KPT 회고

K - Keep

• 코드 컨벤션 및 규칙을 잘 지키고 브랜치 기능 분리로 충돌이 적었다.
• 적극적으로 코드 리뷰를 남겨 개선점을 찾도록 노력하고 수용하는 자세를 가져 의견 충돌이 적었다.
• 새로운 기능과 추가 기능을 찾아 프로젝트 품질을 향상시켰다.

P - Problem

• 회고 작성 및 기록을 미뤘다.
• 캐러셀 컴포넌트가 라이브러리로 만들어 이를 사용하는 라이브러리 자체 에러 때문에 팀원이 어려움을 겪었다.

T - Try

• 다음 프로젝트부터 매일매일 기록하는 습관을 가지고 회고 작성을 미루지 않아야겠다.
• 라이브러리에 의존하지 말고 직접 구현하는 능력을 키워야겠다.