프로젝트 소개
프로젝트 명
DIEDIE.gg
기획 의도
- 리그 오브 레전드 게임 내 비매너 유저를 신고하고, 신고 전적 및 유저 정보를 확인할 수 있는 서비스
프로젝트 설명
프로젝트 기간
- 23/08/04 ~ 23/09/05 (프로젝트 주제 선정 및 담당 파트 구현 기간 전체)
사용 기술
| Library | React |
| Programming Language | TypeScript |
| Styling | Styled-Components |
| State Management | Recoil, Tanstack-Query |
| Formatting | ESLint, Prettier |
| Version Control | Git, GitHub |
| Design | Figma |
| Communication | Notion, Slack |
기술적 의사 결정
| TypeScript | - 정적 타입 언어인 타입스크립트 학습 및 타입스크립트를 이용한 프로젝트 구현을 위해 선정 |
| Recoil | - 리덕에 비해 상대적으로 간편한 사용성 - 컴포넌트 간 데이터 전달을 간소화할 수 있어 상태 관리 코드 작성이 용이해 프론트엔드 팀원들 간의 협업에 유리하여 선정 |
| Chart.js | - 데이터 시각화를 간편하게 해결할 수 있으며, HTML5 캔버스를 이용해 차트를 생성하므로 브라우저 호환성 및 성능이 상대적으로 우수함 - 다양한 차트 유형을 제공하고 데이터 시각화를 클라이언트 측에서 처리하므로 서버로의 추가 요청이 필요하지 않은 장점이 있어 선정 |
| React-Paginate | - 페이지네이션의 빠른 구현을 위해 라이브러리를 사용했으며, React-js-pagination은 부트스트랩 기반이지만 React-Paginate는 디자인이나 스타일의 종속성이 없어 선정 |
프로젝트에서 나의 역할
- 프로젝트 초기 세팅
- 공통 컴포넌트 제작
- http method 호출 및 응답 try-catch 코드 추상화
- 사용자 정보 및 신고 내역 조회
- 프로젝트 진행 과정 문서화
KPT로 프로젝트 돌아보기
📢 KPT는 담당 역할 중 일부에 대해서만 작성했습니다.
프로젝트 초기 세팅 & 공통 컴포넌트 제작
타입스크립트 강의는 많지만 리액트 + 타입스크립트는 폴더 구조를 어떻게 만들고, 어떻게 세팅해야 하는지 자료를 찾기가 상대적으로 어려웠다. 초기 세팅하는 법도 익힐 겸 구글링 해가며 TS CRA를 두 번 정도 만들어보고, 내용을 정리해 팀원들에게 공유했다.
UI를 각각 구현하다가 나중에 중복되는 부분을 합치는 것보다 초기에 빠르게 공통 컴포넌트를 제작하고 배포하는게 효율성 측면에서 훨씬 낫다고 생각했다. 또한 이전 프로젝트에서도 UI 공통 컴포넌트들을 만들어 전체적인 프론트 구현 시간이 줄어들었던 경험이 있기에 초반에 빠르게 작업을 진행했다.
Portal을 이전 프로젝트에서는 만능 버튼처럼 Portal 하나에 내려오는 props를 이용해 모달을 구현했는데, 이번엔 각각의 모달에서 띄워주는 화면이 다 달라 props로 분기처리를 진행해 분기값에 따라 다른 포탈을 렌더링 할 수 있도록 구현했다. 이렇게 하면 가능할 것 같은데? 라고 머릿속으로만 생각했던 코드를 직접 구현해 내니 성취감이 엄청났다.
항상 만들어두는 이미지 공통 컴포넌트에 onError를 처음 적용해보았다. 사용자가 업로드한 이미지도 있지만 라이엇 api에서 URL로 가져오는 이미지도 많기 때문에 onError가 필요했다. 실제로 인게임에는 존재하지만 api에서는 가져오지 못하는 이미지 URL들이 있었고 onError를 적용해 둔 덕분에 response값의 URL이 에러일 경우 default 이미지를 출력할 수 있었다!
Keep
- 능동적으로 초기 세팅을 진행한 것
타입스크립트 기본 개념만 익히고 진행하는 첫 프로젝트여서 리액트에 어떻게 적용해야 하는지 처음엔 막막했는데, 천천히 자료를 찾아보고, 정리하고, 직접 실습해보면서 언제나 그렇듯 하면 되는구나를 느낄 수 있었다. 그리고 직접 부딪혀봐야 이해가 세 배로 잘되는 타입이라 구현하는데 더 많은 도움이 됐다😄
Problem - Try
- Storybook 적용
공통 컴포넌트를 제작했던 이전 프로젝트에서도 UI 컴포넌트를 시각적으로 함께 테스팅할 수 있는 스토리북에 대해서 알게 되었었는데, 프로젝트 말미에 알게 되어 도입하지 못했었다. 이번 프로젝트에서도 타입스크립트를 이용한 구현에 더 초점을 둬서 스토리북을 적용하지 못했는데, 팀 프로젝트에서 공통 UI 컴포넌트를 제작해 배포할 거라면 스토리북을 사용해보고 싶다. 제대로 구현이 됐는지 디자이너님과도 시각적으로 소통할 수 있고 팀원들도 코드만 보는 것보다 더 잘 이해할 수 있을 것 같다. 꼭! 올해가 끝나기 전에 다른 사이드 프로젝트에서 스토리북을 써보리라.. (회사에서 쓰면 더 좋고)
코드 추상화
이전 프로젝트에서 axios interceptor를 구현하며 token값을 넣는 함수를 공통화하는데는 성공했지만, response 부분은 방법이 생각나지 않아 처리를 진행하지 못했다. 코드에서 항상 똑같이 쓰게 되는 then-catch문을 보며 어차피 중복되는데 하나로 처리할 방법이 없을지가 마음에 걸렸었는데 이번 프로젝트에서 드디어 추상화를 적용해 코드를 간결하게 만들었다. 코드 리뷰 중에 이 내용이 번뜩 정리가 돼서 예시 코드를 함께 남겨드렸고,
적용해서 중복되던 response 예외 처리 구문이나 api 호출까지도 간결하게 처리할 수 있었다!
다른 화면에서도 분기값만 다르고 나머지는 똑같은 UI로 렌더링 되는 부분이 있었는데, 그 부분도 변수를 이용해 반복되던 같은 코드를 추상화시켰다. 정리하는걸 좋아해서 코드가 깔끔해지거나 효율성 있어지면 정-말 행복하고 뿌듯하다👼
Keep
- 중복되는 코드 공통화하기
간결한 코드가 항상 좋은 효율을 내는건 아니지만, 그래도 유지보수나 가독성 측면에서 중복을 최소화해 라인수를 줄일 수 있다면 줄이는 게 좋다고 생각한다. 이번 프로젝트에서 계속 고민하던 부분들에 추상화를 적용할 수 있어서 좋았다. 지금의 코드를 잘 기억해 뒀다가 다음엔 이 코드를 기반으로 더 좋은 코드를 구현할 수 있을 거라 생각하면 더 기쁘고.
Problem - Try
- 이 코드가 최선인지에 대한 고민
공통 컴포넌트를 만드는 것도, 추상화를 적용하는 것도 최대한 같은 팀원들이 사용하기 편하게 만드려고 노력하는 편인데, 어려운걸 쉽게 설명하는걸 지향하기 때문에 다른 분들이 봤을 때 이해하기 쉬운 코드인지가 궁금하다. 코드를 완성해도 이것보다 더 좋은 방법이 있지 않을까? 두 번, 세 번 생각하는데.. 더 좋은 방법이 생각나지 않을 때 이게 정말 최선이라 그런 건지 아니면 배울게 아직 남아서 그런 건지 명확하게 답을 내릴 수 없어 답답하다. 아직 주니어기 때문에 당연히 후자일 거라 생각하는데 그렇다면 뭘 더 배워야 더 좋은 코드를 짤 수 있을까? 에 대한 물음이 생기기도 하고. 이 부분은 시간과 노력이 해결해 줄 거라 믿는다.
사용자 정보 및 신고 내역 조회
유저 정보 조회
메인페이지 검색창에서 유저를 조회해 해당 유저를 클릭하면 유저 정보 페이지로 랜딩된다. 계정이 있는 유효한 사용자일 경우 게임 프로필 이미지, 유저 정보, 신고 유저 TOP 100중 몇 위인지, 승률, 출몰 지역, 플레이 타임, 신고 카테고리 및 출몰지역 통계, 신고 내역을 조회할 수 있다.
통계는 Chart.js를 이용하여 데이터를 시각화하였으며 하나의 Chart.tsx 컴포넌트 내에서 flag값(response 데이터의 길이는 각각 4개, 6개 고정이므로 response의 length를 flag값으로 사용했다.)을 이용해 데이터를 구분해 각각 출력할 수 있도록 구현했다.
존재하지 않는 유저일 때
존재하지 않는 유저 닉네임일 경우 useQuery의 error와, navigate를 이용해 에러 페이지로 랜딩 될 수 있도록 구현하였다.
휴면 계정이거나, 통계 데이터가 존재하지 않을 때
조회한 유저의 롤 계정이 휴면 계정이라면 주 출몰 지역에 겨울잠 자러 갔다는 문구를 띄워주었다. 또한 신고 데이터가 없을 경우 등록된 신고가 없다는 문구를, 신고 및 게임 데이터가 없어 출력할 차트가 없을 때도 등록된 통계 데이터가 없다는 문구를 띄워주었다.
유저 신고 내역 페이지네이션
유저 신고 내역은 한 페이지에 5개씩 보여지는 페이지네이션으로 구성하였다. 컴포넌트 상하관계와 useQuery 데이터 감지 관련해서 2시간 가까이 사투를 벌였었는데, 트러블 슈팅으로 따로 기록할 예정..!
신고 내역은 더보기 버튼 클릭 시 숨겨졌던 추가 영역이 토글 되도록 state를 boolean값으로 관리했고, 스크린샷 부분에 있는 사진을 클릭할 경우 해당 사진만 자세히 볼 수 있도록 Portal을 이용해 사진만 별도의 모달로 띄워주었다.
인게임 정보 조회
조회한 유저의 인게임 정보 클릭 시, 해당 유저가 현재 게임 중일 경우 실시간 게임 데이터를 조회한다. 이때 유저가 진행 중인 맵 기본 정보, 닉네임, 티어, 신고 내역이 있다면 신고 횟수와 신고 최대 누적 카테고리를 보여준다. 신고 내역이 없다면 모범시민이라는 문구를 출력해 주었다.
조회한 유저가 게임 중이 아닐 때
조회한 유저가 게임 중이 아니라면 현재 게임 중이 아니라는 문구를 보여준다.
Keep
- 안되면 될 때까지 하기
타입스크립트로 프로젝트를 처음 구현해 보면서 생소한 타입 에러들을 많이 만났다. 처음엔 정적 타입이라서 이런 에러도 뜨는구나 싶었는데 6 depth, 7 depth의 타입 에러 오류도 마주치면서 이게 대체 뭔가.. 싶은 순간도 있었다🤔 그렇지만 어떻게든 해결한다는 생각으로 구글링 하고, 스택오버플로우를 보고, 지피티한테 물어보면서 결국 완성했고 타입스크립트도 전보다 친숙해진 느낌이다.
Problem - Try
- 좋은 코드를 더 많이 보기
위의 P-T와 마찬가지로 타입스크립트로 진행하는 첫 프로젝트이다 보니 이 코드가 맞는 코드인가? 에 대한 궁금증이 해소되지 않았고, 어떤 참고 자료를 보면서 프로젝트 폴더 구조, 타입스크립트 + 리액트에서 코드 작성하는 법 등을 익혀야 할지 잘 모르겠다. 구글링도 좋은 글이 많지만 처음 배우는 분들의 글도 많기 때문에 정제해서 보기 쉽지 않았다. 좋은 구조의 프로젝트를 하나 찾아서 클론을 해보거나 찬찬히 뜯어보면서 내 것으로 체화하는 시간을 가지고 싶다.
회고를 마치며
나는 롤을 안 한다.. 스무 살 초반에 AI만 조금 해봤고 (AI 몇 판 하고 인게임 들어갔다가 부모님 안부 묻는 분위기보고 충격 먹음) 가르쳐줄 테니 같이 하자는 얘기들도 거절했었는데 롤 관련 프로젝트를 할 줄은 생각도 못했다. 주제도 모른 채 팀원들이 좋아서 시작한 거라, 흥미 없으면 시작도 못하는 내가 관심 없는 분야 개발을 잘할 수 있을까? 하는 걱정이 조금 있었다. 그럼에도 불구하고 구현하는 게 재밌어서 프로젝트에 정이 붙었고 롤이 뭔지도 조금 배웠다는 점.. 팀원들이랑 타입스크립트 에러 잡는 것도 해프닝마냥 즐거웠고 내가 개발 자체를 그냥 재밌어한다는 걸 다시 한번 느낄 수 있었다.
이제 구현이 끝났으니 작성한 코드를 되짚어가며 구현하느라 까먹은 타입스크립트 개념을 다시 복습해 보고, 리팩토링할 부분이 추가적으로 더 있는지 찾아보려 한다. 공부한 내용 블로그에도 정리해 보자!
'Diary > Retrospective' 카테고리의 다른 글
| [1년차 회고] 무언가를 찾아 떠나는 여정은 항상 초심자의 행운으로 시작해서 잔인한 시험으로 끝난다 (6) | 2024.10.27 |
|---|---|
| [항해99 수료 회고] 🚢 99일간의 항해를 마무리하며 (3) | 2023.07.06 |
| [항해99 / TIL] 🚢 23-05-25 짧은 일기 (2) | 2023.05.25 |
| [항해99 / TIL] 🚢 23-05-03 리액트 query, axios로 게시판 만들기 (4) | 2023.05.03 |
| [항해99 / TIL] 🚢 23-04-29 Styled Components로 화면 요소 만들기 (0) | 2023.04.29 |
