Elli-Lee 님의 상세페이지 ＞ [4팀 이유진] Chapter 2-3. 관심사 분리와 폴더구조

[4팀 이유진] Chapter 2-3. 관심사 분리와 폴더구조

by Elli-Lee2025. 8. 11.

https://elli-lee.github.io/front_6th_chapter2-3/

늦게 채점해주새오....🫶 PR 적는 중임니다아아

과제 체크포인트

기본과제

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

최종과제

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

과제 셀프회고

이번 과제는 AI 도움 거의 없이 진행했습니다. 회사에서 리액트를 사용하지 않아서 이 기회에 리액트를 제대로 경험해보고 싶기도 했고, 4,5주차에 배웠던 내용들을 최대한 스스로 적용해보고 싶었거든요! 과제를 딱 처음 받았을 때는 뭐부터 분리해야 할지 여느때처럼 막막했는데요, 4,5주차를 경험하고 나니 그래도 전보다는 수월하게 분리를 하고 있다는게 스스로 느껴졌어요. 아직 많이 부족해도 지난주보단 조금이라도 나아졌구나...!가 느껴져서 기뻤습니다. 과제를 하는 과정에서 느꼈던건,, 작은 부품으로 쪼개두고 그걸 몇개 뭉쳐서 entity, feature, widget 단위로 만들고, 또 이렇게 뭉친 걸로 페이지를 조립하는것 같은...음 마치 레고를 하는 기분이었습니다. 코드가 되게 구조적으로 일관성 있게 정리되고 있는 느낌이었고, 같은 걸 다루는 것끼리 뭉쳐놓으니까 찾기도 수월했습니다.

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

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

테오가 멘토링때 해주셨던 [ 일단 결합도를 낮춰놓으면 응집도를 높이는건 어려운게 아니다! ] 라는 말을 계속 생각하면서 과제를 진행했어요. 그래서 이번 과제를 하면서 계속 생각하고 고민했던건.. 결합도를 낮추자. 어떻게 낮추지...? 였고, entity, feature, widget 중 이걸 어디에 둘지는 사실 상대적으로 덜 고민했던것 같습니다. 그 대신 entities > feature > widget > pages 로의 단방향 의존성은 반드시 지키려고 했습니다.

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

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

챕터 셀프회고

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

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

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

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

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

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

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

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

과제 피드백

수고했습니다. 지난 3주간 클린코드를 비롯한 소프트웨어 공학적으로 결합도 낮추기 응집도 높이기를 위한 이론과 프론트엔드에서의 적용등을 통해서 좋은 코드와 구조에 대한 다각도의 시야가 생겼기를 기대합니다.

"이번 과제는 AI 도움을 최대한 받지 않고 진행했습니다. 회사에서 리액트를 사용하지 않아서 이 기회에 리액트를 제대로 경험해보고 싶기도 했고, 4,5주차에 배웠던 내용들을 최대한 스스로 적용해보고 싶었습니다."

"과제를 딱 처음 받았을 때는 뭐부터 분리해야 할지 여느때처럼 막막했는데요, 4,5주차를 경험하고 나니 그래도 전보다는 수월하게 분리를 하고 있다는게 스스로 느껴졌어요. 아직 많이 부족해도 지난주보단 조금이라도 나아졌구나...!가 느껴져서 기뻤습니다."

"테오가 멘토링때 해주셨던 [ 일단 결합도를 낮춰놓으면 응집도를 높이는건 어려운게 아니다! ] 라는 말을 계속 생각하면서 과제를 진행했어요."

"FSD 보다는, 결합도를 낮춰야 한다!는 말을 계속 생각하며 개발을 하고 싶습니다. 결합도가 낮으면 유지보수면에서도 훨씬 좋을 것 같은데, 어떻게 결합도를 낮출 수 있는지, 어떻게 하면 분리를 잘 할 수 있을지는 조금 더 많은 연습과 고민이 필요합니다."

코드를 살펴봤는데 잘했습니다. 결합도를 낮춰둔 것이 실제로 도움이 되는지는 나중에 그렇게 분리해둔 코드로 요구사항 수정과 개선 과정에서 어려움을 겪지 않을 때 느낄 거에요. 이게 웃긴게 결합도를 낮춰놔서 일을 쉽게 한건 사실 체감이 잘 안되요. 안될때에만 뭔가 이상하다 느끼기 때문이죠.

"실무에서 사업 요건에 따라 유지보수 해야하는 경우가 종종 있는데, 어떤 코드는 유지보수하기 쉽고, 어떤 코드들은 그렇지 않다는 걸 매번 느꼈습니다. "

에서 그렇지 않은 코드들을 경험하는게 적은 것으로 느껴보기를 바래요! 이번에 과제를 하면서는 결정과 선택을 하는데 에너지를 많이 써서 힘들게 느껴졌겠지만 어느순간 이렇게 하는게 편하네 하는 것들은 별 에너지 없이 좋은 코드를 작성하고 있을 거에요.

화이팅입니다! 수고많았어요!

Q. 사실 저는 대부분 사람들이 그렇게 사용하니까 배럴파일을 사용해서 export를 하고 있긴 한데요... 사실 import 할 때 경로가 간단해서 보기 깔끔하다..! 말고는 좋은점을 모르겠어요. 오히려 index.ts 파일이 너무 많아져서 어느 계층에 있는 index 파일인지 체크하면서 개발하기가 오히려 더 불편한 것 같은데, 제가 배럴파일을 잘못 쓰고 있어서 그 장점을 못느끼는건지 궁금합니다..!

=> 의견이 분분한거 보면 여기도 정답보다는 취향의 영역인것 같습니다. 개인적으로 배럴파일을 좋아하지 않습니다. 배럴방식의 장점은 하위 레이어의 구현 코드를 수정하고 변경해도 상위 계층의 import를 변경하지 않아도 된다는 장점이 있죠. 또한 외부로 export해야하는 것을 한 곳에서 보고 관리할 수 있다는 면이 있습니다. import 문이 깔끔한것도 있지요.

=> 반면 tree-shaking이나 관리의 복잡도 index파일이 늘어나는 것. 그리고 index파일을 알아보기 어렵다는 단점이 존재합니다. 장점이 단점보다 좋은냐 하는 점인데 저 개인적으로는 장점이 단점을 압도한다 보기 어려워 저는 배럴을 사용하고 있지 않아요. 유진도 그렇게 느꼈다면 사용하지 않아도 좋습니다. 언제나 지금처럼 본인이 직접 경험해보고 판단하는건 중요한것 같아요. 그리고 언제든 또 상황에 따라 바뀔 수 있기에 최대한 장점을 느껴보고자 노력을 하면서 마음을 열어두는것과 그래도 본인의 느낌을 믿고 결정하는 것이 필요할거에요. 스스로를 충분히 믿을 수 있을 만큼 이해해보고 결정하면 될것 같아요!

BP 선정 이유: 작성한 코드가 일관성 있게 충분히 결합도가 낮은 좋은 구조로 분리를 했기에 참고가 될 수 있을거라 생각하여 선정하였습니다.