[6팀 김보경] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍

[bokim1004]

배포링크

https://bokim1004.github.io/front_5th_chapter2-2/index.origin.html
https://bokim1004.github.io/front_5th_chapter2-2/index.refactoring.html

과제의 핵심취지

• 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의 책임에 맞도록 코드가 분리가 되었나요?

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

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

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

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

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

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

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

심화과제

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

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

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

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

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

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

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

과제 셀프회고

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

계층구조 고려하여 개발하기

실무에서 개발을 했을 때는 계층 구조를 따져서 개발하기보다는, 복잡한 컴포넌트는 쪼개고, 뷰 로직과 비즈니스 로직을 분리하는 정도만 했었습니다.

이번 과제를 진행하면서, 계층별로 설계를 먼저 하고 그에 맞게 개발을 진행하였습니다. "안정적이고 변하지 않는 뼈대부터 다듬자" 는 마음으로 아래의 순서대로 개발을 진행했습니다:

1. entities 폴더 만들고 도메인 객체 타입화하기
2. calculation폴더 만들고 계산함수 순수화
3. store설계 - 상태를 모듈별로 나눔
- 상태만 가지고 있고 로직은 훅/계산으로 분리
4. 로직 정리 - HOOKS
5. 화면 구성 features
6. 공통컴포넌트 분리 UI
7. page 분리

이와 같이 계층별로 순차적으로 개발을 하다 보니, 안정적인 프로젝트 기반을 쌓는 느낌이었습니다. 이렇게 진행하니 전체적인 흐름을 명확히 파악할 수 있었고, 더 효율적으로 개발할 수 있었습니다. 만약 계층 구조를 고려하지 않고 개발을 했다면, 여기저기 왔다 갔다 하면서 시간을 비효율적으로 사용했을 것이라고 생각합니다.

특히, 엔티티별로 구분하는 방식은 처음 시도해봤는데, 로직, 훅, 기능 폴더 내의 코드를 coupon, discount, product, cart와 같은 엔티티별로 나누니, 코드 수정이나 리팩토링 시 매우 편리하다는 생각이 들었습니다.
어디에 코드가 있는지 예측이 쉬워져서, 리팩토링 시 훨씬 효율적이라는 점을 확실히 느꼈습니다.

폴더 구조를 나눌 때도 아래와 같이 계층 구조를 고려하여 나누려고 했습니다.
특히 엔티티별로 신경써서 features,hooks을 나누고 개발을 진행했습니다.

Folder Structure 📁

🔧 refactoring 폴더

• 💡 calculations - 순수 계산 함수

  • apply-coupon.ts
  • calc-discount-rate.ts
  • calc-total-discount.ts

• 🧩 components - UI 레이아웃

  • layout.ts

• 📊 data - 초기 데이터

  • index.ts
  • initialCoupons.ts
  • initialProducts.ts

• 🏷️ entities - 도메인 객체 및 도메인 컴포넌트

  • 🛒 cart - 장바구니
    • cartItem.ts
  • 🎟️ coupon - 쿠폰
    • coupon-input-form.ts
    • coupon.ts
  • 💸 discount - 할인
    • discount-input-form.ts
    • discount.ts
  • 📦 product - 상품
    • product.ts

• ⚙️ features - 사용자 및 관리자 기능으로 분리

  • 👨‍💻 admin - 관리자 페이지

    • 🎟️ coupon - 쿠폰

      • coupon-manage-section.ts

    • 💸 discount - 할인

      • discount-edit-form.ts

    • 📦 product - 상품

      • new-product-form.ts
      • product-edit-form.ts
      • product-item.ts
      • product-list.ts
      • product-manage-section.ts

  • 👤 user - 사용자 페이지 (장바구니 페이지)

    • 🛒 cart - 장바구니
      • cart-list.tsx
      • cart-price-summary.tsx
      • cart-section.tsx
    • 🎟️ coupon - 쿠폰 관련
      • coupon-section.tsx
    • 📦 product - 상품 관련
      • product-section.tsx

• 🎣 hooks - 로직 hook으로 분리

  • 🛒 cart - 장바구니

    • useCart.ts

  • 🎟️ coupon - 쿠폰 관련

    • useCoupons.ts
    • useSelectedCoupon.ts

  • 💸 discount - 할인

    • useDiscount.ts
    • useDiscountCalculator.ts

  • 📦 product 상품

    • useEditProductAction.ts
    • useProduct.ts

  • shared 재사용 가능한 hook

    • useToggle.ts

• 🧠 logic - 비즈니스 로직

  • 🛒 cart - 장바구니
    • cart-logic.ts
  • 📦 product 상품
    • product-logic.ts

• 📑 pages - 페이지 컴포넌트

  • AdminPage.tsx
  • CartPage.tsx

• 🗄️ store - 상태 관리 스토어

  • cart-store.ts 장바구니 관련 상태
  • product-store.ts 상품 관련 상태

• 💻 ui - UI 구성 요소 - 재사용 가능한 UI

  • button.tsx
  • card-with-title.tsx
  • form-input.tsx
  • input.tsx
  • list-wrapper.tsx

• ⚙️ utils - 유틸리티 함수들

  • formatter.ts
  • percentUtils.ts

계층구조를 고려하여 단계별로 개발을 하다보니, 데이터의 흐름도 더 파악이 쉬웠습니다.

---

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

Hook 폴더에서 엔티티별로 훅을 나누긴 했지만, 돌아보면 조금 더 세분화할 수 있지 않았을까 하는 생각이 들었습니다.
명확한 기준을 가지고 역할에 따라 훅을 쪼개고 정리했더라면, 유지보수나 확장성 측면에서도 더 좋았을 것 같아요.

또한, 시간이 조금 더 있었다면 컴포넌트도 더 잘게 나눠서 역할별로 명확하게 구분했으면 좋았을 것 같다는 아쉬움도 있습니다. 전체적으로 기능 단위로 분리하긴 했지만, UI 재사용성과 가독성 측면에서 더 다듬을 수 있었겠다는 생각이 들었습니다.

---

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

entities 폴더 내에 coupon-input-form, discount-input-form 같은 엔티티 컴포넌트를 추가해보았는데요. 개발을 마치고 나니 이 컴포넌트들이 오히려 features 폴더에 들어가는 게 더 적절하지 않았을까? 하는 고민이 들었습니다.

멘토링 중에 "entities는 DB나 데이터 중심, features는 기획 또는 API와 관련된 구현"이라고 설명해주셨는데, 여전히 이 두 폴더의 구분이 조금 애매하게 느껴집니다.
특히 제가 작성한 input-form 컴포넌트들은 어디에 두는 게 가장 적절할지에 대한 판단이 어려웠습니다.
이런 경우 어떤 기준으로 구분하면 좋을지 궁금합니다~!