과제 링크
https://k-sang-soo.github.io/front_6th_chapter2-3
과제 체크포인트
기본과제
목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기
- 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
- Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
- FSD(Feature-Sliced Design)에 대한 이해
- FSD를 통한 관심사의 분리에 대한 이해
- 단일책임과 역할이란 무엇인가?
- 관심사를 하나만 가지고 있는가?
- 어디에 무엇을 넣어야 하는가?
체크포인트
- 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
- Props Drilling을 최소화했나요?
- shared 공통 컴포넌트를 분리했나요?
- shared 공통 로직을 분리했나요?
- entities를 중심으로 type을 정의하고 model을 분리했나요?
- entities를 중심으로 ui를 분리했나요?
- entities를 중심으로 api를 분리했나요?
- feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
- feature를 중심으로 ui를 분리했나요?
- feature를 중심으로 api를 분리했나요?
- widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?
심화과제
목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기
- TanstackQuery의 사용법에 대한 이해
- TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
- 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해
체크포인트
- 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
- 쿼리 키가 적절히 설정되었는가?
- fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
- 캐싱과 리프레시 전략이 올바르게 구현되었는가?
- 낙관적인 업데이트가 적용되었는가?
- 에러 핸들링이 적절히 구현되었는가?
- 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
- 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
- TanStack Query의 Devtools가 정상적으로 작동하는가?
최종과제
- 폴더구조와 나의 멘탈모데일이 일치하나요?
- 다른 사람이 봐도 이해하기 쉬운 구조인가요?
과제 셀프회고
이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.
본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?
아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.
이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.
챕터 셀프회고
죄송합니다 열심히 작성 중에 있습니다.ㅠㅠㅠㅠㅠㅠㅠㅠ
클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.
클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기
- 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요
결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리
- 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요
응집도 높이기: 서버상태관리, 폴더 구조
- "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
과제 피드백
수고했습니다. 지난 3주간 클린코드를 비롯한 소프트웨어 공학적으로 결합도 낮추기 응집도 높이기를 위한 이론과 프론트엔드에서의 적용등을 통해서 좋은 코드와 구조에 대한 다각도의 시야가 생겼기를 기대합니다.
"FSD를 유튜브, 블로그 등에서 듣기만 했고, 실제로 사용해본적은 없었는데 이번에 사용하면서 느꼈던 점은 아토믹 디자인 시스템을 만들었을 때와 비슷한 느낌이 받았습니다."
"하지만 공통적으로 느낀 단점은 원칙을 봤을 때는 각 레이어나, 단위 별로 정갈하게 정리된 서제처럼 모든 게 정확히 나누어질 것 같은데, 막상 실제로 도입해서 실무에서 경험을 하다보면 이 컴포넌트나 로직들을 어디다 둬야할지 애매모호한 부분들이 많았습니다. 뭔가 각 레이어나 단위 별로 한 다리씩 걸친 것 같고, 귀에 걸면 귀걸이 코에 걸면 코걸이 같은 느낌이 들었습니다. 그래서 이걸 의미있게 만들기 위해서는 동료 개발자들과 충분히 논의하고 롤을 정립해야되는데 이런 과정에서 굉장히 많은 시간이 소모되고, 끊임없는 고민과 선택 장애들이 이어져 피로감이 쌓이는 점은 단점으로 느껴졌습니다."
맞습니다. 사실 FSD는 그동안 FE코드를 작성하다보니 어렴풋이 이런식으로 나눠지는것 같다는 아토믹 디자인 시스템과 같은 일종의 설명가능한 멘탈모델에 가깝습니다. component, hooks, services, utils, types의 기존 방식과 달리 모든 사람이 이 이론에 따라서 완벽하게 나눠서 만들어지는 형태는 아니기에 의의는 제공하지만 표준이 되지는 못하는 방식이죠.
"동료 개발자들과 충분히 논의하고 롤을 정립해야되는데 이런 과정에서 굉장히 많은 시간이 소모되고, 끊임없는 고민과 선택 장애들이 이어져 피로감이 쌓이는 점은 단점으로 느껴졌습니다."
충분히 일리가 있는 말입니다. 반대로 말하면 좋은 규칙을 정하게 되면 앞으로 발생하는 고민과 선택에서 발생하는 피로감을 줄일 수 있다는 의미이기도 합니다. 규칙이 없다는게 좋은 규칙은 아니니까요. 그 규칙으로써 FSD가 모두가 납득하는 규칙은 아닐지언정 참고하기에 이만큼 세부적인 내용이 있는게 없기도 합니다. 그렇지만 이게 FSD를 써야만 하는 이유가 되지는 않는거죠.
결합도는 낮게 응집도는 낮게 단일 책임을 가지고 가독성을 높인 일관성 있는 구조는 좋은 코드인건 분명 맞는데 그게 정확하게 뭐다 라고 정의하기에는 세상도 생각도 환경도 변합니다. 원칙과 트렌드에 맞게 더 나은 것들을 발견해가는 과정이겠죠. 그 과정 중에서 대다수가 합의하는 방식은 표준이 되어가고 아직 모르겠다 하는 것들은 논의등을 통해서 더 나은 것들을 발견해 나가는게 개발의 과정이라고 생각합니다.
표준이 정답은 아니지만 표준이기에 배워야 하는게 있고, 논의가 되고 있는 것들에 대해서도 각 관점과 방향성이 어째서 제시되는가에 대해서도 함께 배워가면서 좋은 선택을 하려고 노력하는 방향으로 성장해가길 바랍니다. 수고많았습니다.
Q) 리액트 쿼리의 캐싱 전략을 실제 서비스에서는 어떻게 가져가는지 궁금합니다. 저는 SI/에이전시에 회사에서 근무하다 보니, 고객 데이터를 기반으로 서비스를 확장해 나가는 경험을 해본적이 없습니다. 생각하기에는 어느 정도 규모가 있는 서비스라면 이러한 데이터를 활용해 다양한 캐싱 전략을 세울 것이라 생각하는데, 실제 현업에서는 어떻게 접근하는지 듣고 싶습니다.
=> 리액트 쿼리의 캐싱 전략이 실제 서비스라고 뭐 특별히 더 달라지는 건 없습니다. 마찬가지로 도메인 기반의 쿼리키를 만들어 관리합니다. 다만 규모가 있는 서비스의 어려움은 깊이라기 보다는 그 규모 그 자체에 있죠. 지금의 과제처럼 만들어진 수많은 코드들을 최신 이론으로 변경하는 것은 쉬운 일이 아니고 과제가 5일짜리였는데 실제 서비스들 이 10배 100배 크다고 생각해보면 산술적인 계산으로도 100주면 1년이 걸리겠네요. 그 과정에서 놓치는것도 뺴먹는 것도 당장 하지 못하는 것들도 여러가지 현실적인 어려움들이 있죠. 그리고 그걸 어떻게 하면 좋을지를 고민하는 거라고 생각합니다.
수고하셨습니다!