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

[milmilkim]

배포링크

https://milmilkim.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를 '그런 게 있다더라'하는 정도로만 알고 있었기 때문에 개념자체가 새로웠다. 이전 과제들은 그래도 어느 정도 아는 것들이었는데 FSD가 과제 중에서 제일 알기 어려운 부분이었다.

디렉토리 구조를 어떻게 꾸려갈지는 개발을 할 떄 항상 어려웠던 부분이다. 일을 할 떄 초도개발을 할 일이 많았는데 그떄마다 구조를 조금씩 바꿔 보았고, 항상 단점이 있었다. 발제나 Q&A에도 나온 얘기지만 2depth는 정해진 게 없어서 어딘가 불편한 느낌이 드는 것이었다. 나의 경우에는 프로젝트 규모가 FSD의 도입을 고민할 정도로 커졌던 일이 없었기에 그냥 구조를 최대한 펼쳐놓고 폴더 구조 고민을 안 하게 하는 것을 선택했다. (컨벤션을 정하기 쉽지 않고 작업자가 자주 바뀌는 환경이었다.)

처음엔 '그래서 이 방식을 왜 써야 하는 거지'하는 생각을 계속 했었는데, 지금은 FSD의 장점을 알 것 같다. 도입하기는 힘든데 그 방법을 정하고 나면 앞으로는 정해진 규칙대로 만들어나가면 되는 것이다.

하나의 프로젝트를 길게 가져간다면 이 방식의 장점이 클 것 같다. 나는 아직 그런 경험이 없어서 잘 와닿지 않았다.

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

FSD 아키텍처의 개념 자체를 이해해보려고 했다.

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

Q&A에서도 다루었던 부분인데, Entity와 Feature 레이어의 구분이다.
다른 레이어들은 좀 헷갈려도 비교적 직관적인데 이 두 가지 레이어는 헷갈린다.
Entity는 명사고 Feature는 동사라는 AI의 비유가 그래도 좀 와닿는 거 같다.

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

FSD도 테스트 코드처럼 다른 사람들의 반발이 있을 것 같다(?)
사실 굳이 FSD를 쓰지 않아도 되는 프로젝트는 기존 방식을 유지하는 게 좋을 거 같고, 확장성이 있는 프로젝트라면 FSD를 도입해보자고 해보고 싶다.
당장은 더 볼륨이 작은 내 토이 프로젝트 같은 것을 FSD로 리팩토링해보면서 다시 개념을 복습해보면 좋을 것 같습니다.

챕터 셀프회고

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

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

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

안 좋은 코드인 건 알겠지만 제가 입사하고 받게 된, 외부 개발사에서 개발한 많은 코드들이 보통 그런식으로 개발되어 있기 때문에 익숙한 느낌이라는 생각을 했습니다. (많은 분들이 같은 생각을 하지 않았을까요. 😅 그렇게까지 유지보수하기 어려운 코드는 아닌 것 같았어요.)

그 방식이 별로 좋은 방식이 아니라고는 생각했었지만 정확히 어떤 원칙을 지키는 게 좋은 코드인지는 말하지 못했었는데 이제 남에게 설명할 수 있을 거 같습니다.

유지보수 하기 쉬운 코드란..? 단순한게 최고인 것 같습니다.

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

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

왜 함수형 프로그래밍을 추구하는가... 전에는 딱히 별 생각 없이 살고 있었는데 몇주간 장점을 알게 된 것 같습니다. 순수함수의 예측 가능하고 테스트하기 쉽다는 것에 공감하게 되었어요.
함수형 프로그래밍이 추구하는 것, React가 설계된 이유, useEffect 훅이 등장한 배경. 모든 게 같은 이야기를 하고 있었습니다. 별 생각 없이 흩어져 있던 것들을 연결해서 이해할 수 있게 되었습니다.

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

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

TanStack Query는 좋은 라이브러리입니다. 이거 없던 시절엔 어떻게 개발을 했을까...?
매번 손으로 구현하던 보일러플레이트 코드들이 몇 줄로 해결됩니다.

FSD는 아직도 완전하게 와닿는 느낌은 아니지만 어쨌든 시도를 해봤다는 것 자체에 의의가 있는 듯 합니다.
다음엔 더 잘 할 수 있을 거 같아요.

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

순수함수로 분리하면 코드가 깔끔해지지만, 때로는 메모이제이션이나 최적화를 위해 컴포넌트 내부에 두는 게 나을 때도 있지 않나요? 둘의 트레이드오프를 어떻게 판단하시는지 궁금합니다.

공통 컴포넌트, 유틸 함수, 타입 등을 모두 Shared에 넣다 보면 결국 Shared 폴더가 거대해질 것 같은데, 내부적으로 세분화를 어떤식으로 가져가면 좋을까요?