우테코 FE- 레벨2 미션 회고

badahertz52·2024년 6월 11일
0

💫우테코_6기

목록 보기
7/17
post-thumbnail

레벨1 때는 미션마다 머지 후 회고를 작성했는데, 레벨2는 정말 정신이 없었다.
머지가 끝나도 리액트 스터디-알고리즘 스터디-테코콕-영어 수업을 준비하다보니 회고할 시간이 없었다. 우테코 레벨2 프론트엔드 모든 미션을 마쳤다. 마지막 미션이 머지되고, 밀린 회고를 작성하려 한다.

바쁘다 바뻐 우테코 짤

(바쁘다 바뻐 우테코)

미션 구현

💳1. 페이먼츠 미션

🖱️ 배포 페이지 바로가기

페이먼츠 미션 구현 모습

🪙2. 페이먼츠 모듈

npm 패키지 주소

🖱️Hooks
🖱️Modal

모달 패키지 구현 모습

모달 패키지 구현 모습

🛒 3. 장바구니 미션

🖱️ 배포 페이지 바로가기

장바구니 미션 구현 모습

🛍️ 4. 상품목록 미션

🖱️ 배포 페이지 바로가기

상품 목록 미션 구현 모습

🌟 미션에서 배운 것들

미션을 구현하면서 다양한 것들을 시도하고 배웠다. 배운 것들을 키워드로 정리해봤다.

📮 키워드

  • 다양한 테스트 라이브러리
    • 스토리북, RTL, MSW, vitest
  • 상태관리
    • React : useState, useReducer
    • Recoil
    • React Query
  • 편의성 : UX,DX
  • 재사용성과 확장성
  • 파일,폴더 관리

다양한 테스트 라이브러리

레벨1과 마찬가지로 레벨2도 다양한 테스트 라이브러리를 사용했다. 미션을 하는 와중에는 테스트 라이브러리의 차이를 잘 느끼지 못했다. 그러나 모든 미션을 끝내고 되돌아보니 필요에 따라 적합한 라이브러리를 선택하면 될 것 같다.

  • 스토리북 : 다른 개발자와 소통 시 유용할 것 같다. 특히 디자인 관련 체크할 때 좋을 것 같다.
  • RTL : 개발 의도대로 사용자가 사용할 수 있는지에 대한 테스트를 진행한다.
  • MSW : API 요청을 가로채서 모킹한 response를 넣어주고 싶을 때 사용한다.
  • vitest: vite로 개발 시, jest보다는 vitest를 사용하는 게 좋다.

상태관리

미션은 react useState ,useReducer -> Recoil -> React Query 순의 상태관리를 사용했다.

Recoil

React, Recoil은 개인 프로젝트에서 써와서 낯설거나 어렵지는 않았다. 다만 Recoil에서 상태관리의 기본적인 설정들로 부딪히는 부분들이 있었다. 비동기 API를 상태관리 시 캐싱 기능이 있는 selector를 사용하고 싶었다. 그러나 selector는 자기 자신을 업데이트하지 못하는 문제가 있었다. 그리고 Recoil에는 상태 삭제 개념이 없어서 장바구니 속 상품들을 삭제할 때 atomFamily,selectorFamily로 관리 시 삭제되는 상품들의 상태가 삭제되지 않는다는 문제도 있었다.
해당 문제들을 고민하고 방법을 찾고 해결책을 선택하는 나름의 판단 기준을 세웠고 이를 리뷰어에게 공유하는 과정을 경험했다. 다행히 내가 내린 판단의 근거에 대해 리뷰어가 동의/이해해 주셨다.
스터디에서 공부한 다양한 Recoil API를 사용해 보지는 못했지만, 라이브러리에서 해당 상태,API의 존재 이유를 생각하고 어떤 것을 사용할 것 인지에 대해 스스로 판단한 것이 좋은 경험이지 않을까 싶다.😁

React Query

드디어!! React Query를 사용해 봤다.🎉 올해 공부 목표 중 하나가 React Query였다. 우테코를 하게 되면서 React Query를 공부할 시간이 없을 줄 알았는데 우테코 미션 덕분에 공부할 수 있었다.

미션에 앞서 스터디에서 React Query를 간략하게 알아본 게 도움이 되었다. 처음 접하는 것을 바로 미션에 도입하려 했다면 당황스러웠을 것 같다. 스터디에서 React Query가 무엇인지 어떤 기능이 있는 지 훑어보고 가니 검색을 할 때 도움이 되었다.

그럼에도 처음 하는 React Query라, 이렇게 해도 되는 건가라는 의구심이 들었다. 아마도 React Query가 비동기 처리 시 도움이 되는 라이브러리로 생각했기 때문이지 않을까 싶다. 그러나 React Query는 '서버 상태 관리를 쉽게 하기 위해 만들어진 라이브러리'이다. query key를 기준으로 캐싱 된 데이터의 존재 여부,staleTime에 따라 서버에서 받은 데이터 상태를 관리하는 라이브러리였던 거다.

React Query로 상태관리를 하는 방향을 잡으니,그 다음부터는 헷갈리지 않고 구현해 나갈 수 있었다. (방향이 정해졌다는 거지 오류가 없다거나 테스트가 쉬웠다는 것은 절대 아니다.💦)

편의성

UX

레벨2는 UX에 대해 보다 신경 썼고 배웠으며 숙제를 받았다. 평소 UX, UI에 관심이 있어서 미션을 하면서 요구사항, 피그마에 없더라도 필요할 것 같다면 만들었다. 페어 미션같이 시간이 촉박한 상황이라면 1차 제출 후에 추가로 구현했고 미션에 여유가 있다면 UI에 더 욕심을 내서 구현했다.

신경 쓴 UX

페이먼츠 미션을 예로 들어서 UX를 위해 요구사항 외에 추가한 부분은 아래와 같다.

페이먼츠 미션

  • CVC 입력 시, 입력 후 카드 뒤집기 애니메이션
  • 입력 폼 필드 단계에 따라 진행 여부를 보여주는 ProgressBar 기능
  • 메인 페이지인 Home과 경로가 없으면 열리는 NonePage UI 변경
  • 등록된 카드 정보 페이지의 카드 미리보기 추가 및 애니메이션
  • 한 자릿수 입력 시 앞에 0 추가

배운 것과 배울 것

DX

페이먼츠 모달 미션에서 페이먼츠에 사용하는 유효성 검사 훅과 모달 패키지를 만들었다. 이전 미션과 달리 해당 미션의 사용자는 해당 패키지를 사용하는 개발자가 되는 것이다. 이때 DX를 알게 되었다.

개발자 경험으로 패키지를 만들 때, 해당 패키지를 사용하는 개발자의 편의성을 생각해야 했다. 일반적인 유저의 사용성을 생각하는 것과 차이가 있었다. 특히 다양한 개발 상황을 가정하다 보니 처음에는 방향을 잡기 힘들었다. 페어와 진짜 막막했다.

이전 경험을 되돌아보며 개발했고, 리뷰어의 리뷰를 통해 '패키지의 목적'이라는 뱡향을 잡고 미션을 구현해 나갔다. 그리고 문서화를 어느 미션때 보다도 열심히 했다. (css module이 빌드한 패키지에 안 먹혀서 styled-components로 바꾸는데 고생 좀 했다... 휴...😮‍💨)

미션 당시에는 느끼지 못했지만,확실히 내가 만들 모달 패키지를 사용하다 보니 수정해야 할 부분들이 보였다. version patch를 진짜 패키지 쓸 때마다 했다.😂 그리고 문서화와 예시 코드는 패키지를 쓸 때 정말 도움이 되었다. 👍

사용자가 마주할 수 있는 다양한 오류에 대응하자!

첫 번째 미션의 리뷰어인 샐리를 통해서 다양한 오류 상황에 대해 어떤게 대응해야하는 지 알게 되었다. (샐리 감사해요!!🥰)

오류라는 것은 서버의 데이터 요청뿐만 아니라 사용자가 경험할 수 있는 다양한 오류를 뜻한다. 프론트엔드는 사용자와 가장 맞닿아 있기 때문에 사용자가 경험할 수 있는 여러 오류 케이스들을 생각하고 이에 대응해야 한다는 것을 느꼈다. 단순히 오류를 이야기하는 데 그치지 않고 사용자가 해당 오류에서 어떤 액션을 취할 수 있는지, 해당 액션으로 유도하는 기능도 구현해야 한다는 것을 알게 되었다. (액션: 새로고침, 홈으로 이동하는 버튼 등)

스크린 리더를 위한 속성 활용

이미지의 상세 설명을 대체할 수 없는 alt의 값 처리, button의 aria-label을 활용, lang에 맞춘 alt 언어 설정 등 스크린 리더 사용자를 위한 다양한 속성들에 대해 알게 되었다. 남은 레벨2 미션 기간에 사용자 접급성, 스크린 리더에 대한 대처 방법들에 대해 공부할 계획이다.

재사용성과 확장성

레벨2에서 시도한 재사용성과 확장성

  • custom hook
  • 합성 컴포넌트 패턴
  • 프레젠테이션 컴포넌트: 태그의 속성, props 전달 받을 수 있도록 타입을 일반화 하기

새로 알게 된 것들

  • 정적 파라미터와 동적 파라미터
  • 컴포넌트 생명 주기와 관련 없는 로직 분리

레벨2에서 ReactQuery말고도 공부하고 싶었던 custom hook, 합성 컴포넌트 패턴을 많이 사용할 수 있어서 좋았다. 처음에는 두려웠지만 자주 사용하다보니 문제 해결책으로 응용도 하는 모습을 보고 뿌듯했다.😆 (리뷰어인 하루에게 칭찬도 받았다 👍🎉)

합성 컴포넌트를 통한 컴포넌트 재사용 문제 해결

문제 해결 💦
합성 컴포넌트를 통한 컴포넌트 재사용
리뷰어 피드백 😆👍
합성 컴포넌트를 통한 컴포넌트 재사용- 리뷰어 칭찬

파일,폴더 구조 및 관리

레벨1에 이어서 레벨2에서도 파일, 폴더 구조를 어떻게 관리해야 하는 지 고민되었다. 레벨2는 갈수록 관리해야 하는 파일들이 많았다. 그래서 미션마다 리뷰어에게 파일,폴더 관리를 어떤 기준으로 하시는지 물어봤다.

🗨️ 도메인 로직을 기준으로 폴더를 만들기도 해요.
🗨️ 페이지, 컴포넌트, api등 기준으로 폴더를 만들 수도 있어요.
🗨️ 하나의 로직에 대한 훅, 테스트,상수는 해당 로직 폴더에 두는 것을 추천해요.
🗨️ vscode의 확장 기능을 사용하면 index.tsx, style.module.css의 경로를 확인할 수 있어요.
🗨️ 스켈레톤은 합성 컴포넌트로 만들어서 관리하기도 해요.

팀의 코드 컨벤션을 따르고, 개발하는 상황이나 개발자의 취향에 따라 파일, 폴더 구조를 정하는 게 달라진다. 정답이자 정설인 구조는 없는 것이다. 다만 공통으로 등장하는 것은 하나의 큰 기능을 중심으로 폴더를 만들고, 해당 기능에 사용되는 상수,API,훅,CSS를 넣어서 관리하는 것을 추천하셨다. 파일들이 많아질수록 하나의 폴더 안에 관련 기능이 있을 때 수정하거나 확인하는 동작이 각자 다른 폴더에 있을때보다 훨씬 수월하기 때문이다.

레벨2 미션에서 실행한 실험들

🙋‍♀️피드백 받을 부분 구체화 하기

레벨2에서는 모든 미션의 pr 메시지에 피드백 받고 싶은 부분들을 적었다.
코드를 자세히 봐야 하는 것들은 코드에 코멘트를 적고 코멘트 링크를 첨부했다.
이렇게 pr 메시지에 피드백 받고 싶은 부분을 적어두니, 리뷰어가 이를 확인하기도 좋았고 받고 싶은 부분에 대해 중점적으로 피드백을 받을 수 있어서 좋았다.

피드백 받을 부분 구체화하기

리뷰를 받은 후 수정하거나 추가로 궁금한 점이 있으면 마크다운의 header를 사용해 질문 부분을 강조해 질문했다.

또한 재리뷰 요청 시, 리뷰 이후에 수정/변경되거나 추가된 기능이 있다면 이를 코멘트로 정리해 두었다.
재리뷰 요청 시 수졍/변경,추가된 기능 설명

🤓구현 의도를 잘 설명하기

잘 피드백 받기 위해서는, 구현 의도를 잘 설명하는 게 중요하다고 생각한다. pr, 재리뷰 요청 시 구현 의도를 잘 설명한다면 리뷰어가 내 코드를 이해하거나 부족한 부분을 짚어줄 기회를 얻게 된다. 리뷰 받을 수 있는 시간은 한정되어 있으니, 한번 받을 때 더 많이 리뷰를 받을 방법이다.

이미지를 첨부하는 것도 좋고 많이 사용한 방법은 순서도, 다이어그램으로 컴포넌트 트리나 구현 로직을 설명하고 기능 간의 비교나 정리가 필요하다면 표를 이용했다.

리드미에 구현 의도를 함께 첨부한 것에 대해 리뷰어의 평가가 늘 좋았다.
문서화하는 것도 에너지를 쏟는 부분이라 미션 구현 후 문서화 작업을 한다는 게 쉽지 않았지만, 문서화에 대한 리뷰어의 좋은 평은 계속 문서화 작업을 이어 나갈 힘이 되었다. 🥰👍(리뷰어의 칭찬을 받고 무럭무럭 잘 자라고 있다! 🌱🚿☀️)

구현 의도를 잘 설명하기

🏃‍♀️주도적으로 구현하기

나름의 기준을 가지고 결정하려고 하시는 모습이 바다의 큰 장점인 것 같네요.

리뷰어의 리뷰를 받고 수정을 이어가면서도 내가 생각했을 때 해야 하는 이유가 분명하다면 리뷰어를 설득하려 했다.

시작은 페이먼츠 미션이었다. 카드 미리보기에서 유효한 데이터일 때에 미리보기에 업데이트하는 게 옳다고 생각했다. 당시 리뷰어에게 구현한 이유에 관해 설명했고 납득시켰다. 첫 번째 설득이 성공하면서 내가 옳다고 생각한 구현을 설득해 봐야겠다는 동력을 얻었다. 그 이후 부터 자신감을 가지고 구현 의도에 대한 질문에 답하거나 역질문을 해나갔다.

주도적으로 구현하기

👂여러 의견 듣기

레벨1 때는 미션에 집중하느라 다른 크루들과 미션에 관해서 이야기를 나누지 못한 게 아쉬웠다. 레벨2부터는 여러 크루들의 의견을 듣기 위해서 미션에 대해서 캠퍼스, 톡방에서 의견을 나누었다. 확실히 여러 방법에 대해서 알게 되어서 시각이 조금 더 넓어진 기분이다. 진행하고 있는 스터디가 여러 개라 리뷰 스터디를 하지 못한 게 조금 아쉽다. (근데 그거까지 하면 레벨2 못버텼을 수도....)

마무리

레벨2 미션은 레벨1에 비해서 해야 하는 것들이 많았다. 고생했지만, 해보고 싶었던 것들, 새로운 것들을 해보고 공부하고 싶은 것들도 생긴 미션이었다.

좋은 점 중 하나는 코드를 짜는 방식에 대해 어느 정도의 감? 나만의 방식을 가지게 된 것이다. 혼자서 코드를 짜다 보니, 첫 팀 협업 이후에 과거에 짠 코드들이 내 멋대로 만든 코드라는 것을 알게 되었다. 그래서 어떤 코드가 좋은 코드인지, 어떤 것을 공부해야 하는지에 대한 갈증이 있었다. 레벨2에서 리뷰어의 리뷰도 받고 react base camp의 실습 코드들도 보고 스터디를 통해서 여러 코드를 봤다. 파일, 폴더 구조와 재사용성과 확장성도 고민해 보고 어떻게 짜야 코드 자체로 설득력있는 코드를 만들 수 있을까를 생각하면서 코드를 짰다.

레벨2의 시작했을 때와 끝났을 때를 비교하면 React에 대해 확실히 늘었다는 느낌이 든다. 이전에는 해야 하는 공부들이 있어서 구멍이 뚫려있던 게 느껴졌다면 지금은 이전보다 메워진 기분이랄까? 아직도 공부해야 하는 것들이 남아있지만, 레벨2에서 그랬듯이 내 것으로 잘 만들 수 있을 것 같다.

그럼,레벨2 방학 잘 보내고 레벨3 팀 미션도 잘 해보는 것으로!!!🦭
여름 도로 애니메이션 gif

profile
세상과 사람을 잇는 개발을 꿈꾸는 프론트엔드 개발자

0개의 댓글