Skip to content

[11팀 민성윤] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍 #57

Open
SeongYoonMin wants to merge 25 commits intohanghae-plus:mainfrom
SeongYoonMin:main
Open

[11팀 민성윤] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍 #57
SeongYoonMin wants to merge 25 commits intohanghae-plus:mainfrom
SeongYoonMin:main

Conversation

@SeongYoonMin
Copy link

@SeongYoonMin SeongYoonMin commented Apr 24, 2025

과제의 핵심취지

  • React의 hook 이해하기
  • 함수형 프로그래밍에 대한 이해
  • 액션과 순수함수의 분리

과제에서 꼭 알아가길 바라는 점

  • 엔티티를 다루는 상태와 그렇지 않은 상태 - cart, isCartFull vs isShowPopup
  • 엔티티를 다루는 컴포넌트와 훅 - CartItemView, useCart(), useProduct()
  • 엔티티를 다루지 않는 컴포넌트와 훅 - Button, useRoute, useEvent 등
  • 엔티티를 다루는 함수와 그렇지 않은 함수 - calculateCartTotal(cart) vs capaitalize(str)

기본과제

  • Component에서 비즈니스 로직을 분리하기

  • 비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기

  • 뷰데이터와 엔티티데이터의 분리에 대한 이해

  • entities -> features -> UI 계층에 대한 이해

  • Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

  • 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

  • 계산함수는 순수함수로 작성이 되었나요

  • 특정 Entitiy만 다루는 함수는 분리되어 있나요?

  • 특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?

  • 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

  • 재사용 가능한 Custom UI 컴포넌트를 만들어 보기

  • 재사용 가능한 Custom 라이브러리 Hook을 만들어 보기

  • 재사용 가능한 Custom 유틸 함수를 만들어 보기

  • 그래서 엔티티와는 어떤 다른 계층적 특징을 가지는지 이해하기

  • UI 컴포넌트 계층과 엔티티 컴포넌트의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

  • 엔티티 Hook과 라이브러리 훅과의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

  • 엔티티 순수함수와 유틸리티 함수의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

과제 셀프회고

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

내가 짠 코드가 내눈에만 보기 좋은코드인지 남이 보기에도 좋은 코드인지에 대한 고민을 하면서 구현하였습니다... 다만... 되돌아보니 새로운 스파게티 코드를 만든기분이라...마음이 착잡하더라구요... 결국 리펙토링하고 클린코드를 작성하는것은 기존에 잘 작동하던 코드를 더 보기좋게 가독성있게 고쳐나가고, 재사용하기 좋고 유지보수하기 좋은 코드를 만들기 위함인데 리팩토링 한 사람만 보기좋고 유지보수하기 좋은 코드라는건 결국 새로운 레거시 코드가 된게 아닐까? 라는 생각으로 과제를 집중하였습니다.

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

첫번째로 FSD에 대한 이해가 부족하였습니다. FSD 구조를 보면서 Model은 정확히 뭘까? 왜 Hook이랑 다른걸까? 라는 고민을 하였고 팀내에서도 이와 관련된 이야기들을 많이 하였습니다. Model은 순수함수인가? Model은 엔티티만을 위한 함수인가? Model이 다른 엔티티에서 사용되면 그건 더이상 Model이 아닌건가? 혹은 Hooks은 순수함수가 아닌 상태와 관련된 함수인가..? 등등 많은 의견이 오갔고, 어째서 이런 구조가 탄생하였는지 고민을 많이 했습니다... 그런데 공부가 부족한상태여서 그런지... 사실 이렇게까지 빡빡하게 지켜야하는 이유에 대해 잘 공감을 못하겠더라구요... FSD 역시 결국 협업하는 환경에서 더나은 개발환경을 위한 패턴이라고 생각이 드는데 제가 혼자일하는 환경에서 시작하였고, 지금도 혼자 일하는 환경이다보니 협업은 어느정도 이러지않을까? 라는 상상으로 해야하는 상황이다보니 더 와닿지 못했던거 같아 너무아쉬웠습니다...

두번째로 테스트코드에 대한 이해도 부족이였습니다. 정확히는 제 코드는 비즈니스 로직에 대한 처리를 ContextAPI를 이용하여 자식요소에서 서로 공유하며 사용할 수있는 상태를 구현하였는데(props drilling 방지), 이를 테스트코드에 적용해서 실제 테스트에서도 올바르게 동작하는지 테스트하는 과정을 직접 겪고 무엇이 문제인지 해결방안을 제시했어야했는데... 테스트코드에 대한 이해가 부족하여 테스트코드에 실제 적용시켜보는 과정을 갖지 못했습니다...

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

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

좀.. 너무 애매한 질문 같은데 개념이 아직 정확히 이해된게 아니여서 질문드려봅니다..! FSD는 기능기반으로 묶는 듯한 인상을 받았는데, 기존에는 컴포넌트는 컴포넌트 폴더에, 훅은 훅폴더에, 유틸은 유틸폴더에, 서비스는 서비스폴더에 이런식으로 기능기반이라기보단 그냥 같은 역할을 가진 친구들 끼리 묶는 느낌이 강했는데... FSD는 feature 안에서 도메인단위로 묶어서 해당 도메인 내에서 역할을 나누는 느낌으로 느껴졌습니다. 제가 이해한게 맞을까요..?ㅠㅠ

Feature와 Entity의 관계가 비슷한듯 다른듯 하게 느낀건 아직 이해가 부족해서 생긴 문제인거 같습니다.. ChatGPT 선생님과 면담을 해본 결과 user 라는 도메인이 있다고 가정할 때 entity는 사용자 정보를 가져오고 조회하는 역할(getUser API로부터 정보받기, zustand에 사용자 정보 담기 등)이고, feature는 사용자 정보를 변경하거나 시스템에 영향을 주는 행위(Login, Logout, 사용자 정보 변경 등)을 한다고 이해가 되었는데.. 그럼 이번 과제의 Cart에서 보면 Entity는 CartList, CartItem과 같은 Cart의 정보를 가져와 보여주는 역할을 하는거고, Feature는 updateCartList, updateCartItemQuantity와 같이 상태에 대한 업데이트를 한다고 생각하면 될까요..?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant