[3팀 김준모] Chapter 3-3 기능 중심 아키텍처와 프로젝트 폴더 구조

[jumoooo]

과제 체크포인트

https://jumoooo.github.io/front_7th_chapter3-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가 정상적으로 작동하는가?

최종과제

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

과제 셀프회고

이번 과제는 금주에 지방 일정이 있어서 전체적으로 시간이 없었습니다... 그래서 심화과제를 못한게 너무 아쉽네요.
주말 동안 심화과제를 추가로 진행해 봐야 할거 같습니다.

과제내에서 분리 FSD 로 분리 할때 아직 FE 계열에서 일을 하지 않아서 그런가 다른 팀원분들 께서 계속 느끼셨던 이질성은 잘 느껴지지 않았습니다. 다만 해봤던 상태관리가 entities 의 도메인 별로 들어간다는게 뭔가 인지 부조화가 걸렸었습니다. 기본과제도 일단 통과 가능 위주로 작성해서 좀더 봐야하는 부분이 있는데 마찬가지로 아쉽습니다. app 을 분리 안한 것도 걸리네요.
프로젝트 초기화해서 다시 떠먹어 봐야겠습니다.

챕터 셀프회고

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

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

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

더티코드를 처음 마주했을 때는 숨이 턱 막히는 느낌이었습니다. 독해가 쉽지 않았고, 코드 구조를 이해하려는 순간 머리가 하얘지는 경험도 자주 했습니다.
클린코드는 유지보수를 위한 목적도 있지만, 개발자가 작업할 때 직접적으로 체감되는 중요성이 더 크다고 느꼈습니다.

읽기 좋은 코드는 관심사가 애매하게 섞이지 않고, 사전 지식이 크게 없어도 명확한 구조로 쉽게 이해할 수 있는 코드라고 생각합니다.
유지보수가 쉬운 코드는 이런 기반 위에서 기능 단위가 명확히 분리되어 필요한 부분만 손쉽게 추가하거나 제거할 수 있는 코드라고 느꼈습니다.

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

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

디자인 패턴을 처음 접했을 때는 막막했습니다. 이미 만들어진 프로젝트에서 패턴을 적용하는 것은 어느 정도 감이 왔지만, 처음부터 생으로 구조를 만드는 건 개발자의 역량이 많이 필요한 일 같아 어렵게 느껴졌습니다.
순수함수는 이름만 알고 있었는데 실제로 적용해보니 코드가 훨씬 깔끔해지고, 변경하거나 추가할 때 부담이 적어서 “아, 이런 느낌이구나” 하고 이해가 확 왔습니다.
또한 함수나 컴포넌트가 어떤 데이터를 다뤄야 하는지 고민하면서 작업한 것이 처음이라, 컴포넌트를 어떻게 독립적으로 분리할지 기준을 잡아가는 과정이 의미 있는 경험이었습니다.

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

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

서버상태관리는 못해봐서 아쉽습니다..
FSD를 적용해보면서 느낀 점은, 개념적으로는 구조가 잘 분리된 것처럼 보였지만 아직 전체적인 FE 구조 자체에 익숙하지 않아서 그런지 여전히 복잡하게 느껴졌다는 점입니다.

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

이런식으로 FSD 에 따라 각 도메인 별로 entities/user/model/store.ts 처럼 store 를 분리해서 넣으면 했갈리지 않나...? 라는 생각을 했는데 어떻게 생각하시나요?
아직 제가 상태관리 부분에 미흡해서 그런 걸 수도 있을거 같습니다만...