과제 체크포인트

https://yhun940731.github.io/front_6th_chapter2-3/?limit=10&sortOrder=asc

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 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가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

• FSD 아키텍처를 알게 됐습니다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

• 최대한 FSD 철학을 녹여서 분리해 보고싶었습니다.

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

• 여전히 entities와 features의 구분이 모호합니다. 설명을 아무리 봐도 모르겠어요.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

• layer, module별로 각각 분리해서 관리해보고싶은 욕심히 커졌습니다. 이전에는 너무 세분화하는 것에 대해 회의적이었지만, 이번 과제를 통해 세분화함으로써 유지보수와 모듈이 깔끔히 정리되는 것에 매력을 느꼈습니다.

챕터 셀프회고

클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

1. 처음 더티코드를 접했을 때, 살면서 이정도 수준의 더티코드는 처음이라 당황한 기억이 있습니다. 더티코드를 리팩토링하면서, 처음부터 아키택쳐를 설계하고 계획 하에 개발을 진행하는게 유지보수 측면에서 얼마나 중요한지 다시 한번 깨달았습니다. 큰 그림을 그려가며 계획 하에 짜내려가는 코드는 이후 수정이 필요할 때에도 많은 불편함을 제거할 수 있을 것 같습니다.

2. 막연했던 "추상화" 개념을 직접 함수를 분리하고 재설계하면서, 추상화에 대한 중요성, 추상화가 개발자에게 가져다주는 가독성에 대한 이점 등으로 중요성을 알았습니다.

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

• 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

1. 순수함수의 중요성도 이번에 절실히 느꼈습니다. 순수하지 못한 함수들은 유지보수할 때, 의존성으로 인해 아예 새로 짜는게 나을 정도의 어려움을 줄 수 있다고 생각합니다. 순수함수로 이뤄진 코드는 필요한 부분만 간단히 수정할 때 큰 이점을 주며, 추상화에도 큰 도움을 줍니다.

응집도 높이기: 서버상태관리, 폴더 구조

• "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

1. feature와 entity를 분리하는 기준을 여전히 모르겠고 어려웠습니다.
2. 시간 문제로 구현하지는 못했지만, layer의 분리 큰 단위로 통합해보고싶다고 생각했습니다.
3. FSD를 보면서 지나친 layer 분리라고 개인적으로 생각했고, 컨벤션과 개념이 명확하지 않을 때, 오히려 혼란을 주지는 않을까 생각합니다.
4. 시간이 부족해서 클린코드 섹션에서 많은 리팩토링을 실행하지 못해 아쉬움이 남습니다. 다만 클린코드의 중요성, 위에서 언급한 순수함수, 추상화, 아키택처 등 다시 한번 상기하는 좋은 기회였습니다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

1. 코드를 분리하다보니 shared에 지나치게 치중된 것 같은데, 분류가 맞는지 모르겠습니다.
2. feature와 entity의 구분에 대해 모호합니다.
3. 저는 개인적으로 feature와 entity를 하나의 layer로 바라보고 통합하는 건 어떨까 생각합니다.