taeyeong0814 님의 상세페이지[6팀 이태영] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍

배포링크

https://taeyeong0814.github.io/front_6th_chapter2-2/

과제의 핵심취지

  • 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는 분리되어 있나요?
  • 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

  • 이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.
  • 어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.
  • Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.  
  • Context나 Jotai를 사용해서 전역상태관리를 구축했나요?
  • 전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?
  • 도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?
  • 전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?

과제 셀프회고

과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?

1. basic 과제 기본과제는 저만의 기준에 맞게 최선을 다해 리팩토링을 진행하였습니다. 나의 리팩토링 기준

처음 정했던 기준대로 리팩토링을 진행하였는데 사실 시행착오도 있었습니다. 처음에 컴포넌트 역할별로 분리하고 models, hooks 분리를 진행하는 중 icons 를 분리하지 않고 파일 분리가 이루어진 상황이었습니다. 이 때 svg 코드들을 다 찾고 분리하는 것이 너무 어려웠습니다. (다행히 origin에 App 파일이 존재해서 그 파일을 통해 분리를 마무리 하였습니다.) 현업에서 이렇게 분리 자체가 안되어 있는 코드를 만날까? 싶긴 하지만 그런 경우 우선 기존 파일을 copy 해 놓고 진행을 하거나 최대한 나눌 수 있는 부분들을 확실하게 체크하고 분리를 시작해야 된다는 것을 깨달았습니다.

가장 큰 깨달음: "순서가 중요하다!!!!"

 올바르다고 생각하게 된 분리 순서
1. 전체 구조 파악 → 2. 컴포넌트 역할별 분리 → 3. Models/Hooks 분리 → 4. 세부사항(icons 등) 정리

 실제 했던 내가 한 순서
1. 컴포넌트 분리 → 2. Models/Hooks 분리 → 3. Icons 분리→ 4. (origin/App 파일로 수정) 

두 번째 깨달음: "계층분리와 의존성 관계"

FSD 방식도 있고 Atomic 방식도 있고 Domain-Driven Design 방식 등 많이 있지만 이번 과제에서는 이런 방식들보다 눈에 보이게 계층을 나누고 Feature 단위까지로 나뉜 상태로도 충분히 괜찮을 것 같아서 이대로 진행을 하였습니다.(테오 hint구조)

  • Models: 다른 계층을 모름 (순수 비즈니스 로직)
  • Hooks: Models를 사용, Components는 모름
  • Components: Hooks를 사용, Models 직접 참조 금지

그래서 의존 방향이 models > hooks > components 로 단방향이여서 그런지 파악하는데 어려움이 크지 않았습니다.

2. advanced 과제

Jotai, 정말 괜찮은 전역상태 관리 라이브러리!

먼저 Jotai 엄청 괜찮은 녀석이구나? 로 시작합니다. 물론 Jotai가 아니라 전역상태 관리 해주는 라이브러리겠지만!!!

심화과제를 시작하면서 가장 놀라웠던 발견Jotai Provider가 없어도 완벽하게 작동한다는 점이었습니다! 공식문서에서는 아래와 같이 를 사용해라 라고 나와 있는 것을 봐서 그냥 적용을 했었는데 Jotai 내부적으로 "Default Store"를 자동으로 생성한다고 합니다. 그래서 안 써도 문제가 없습니다!

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
     <Provider> //생략 가능
       <App />
     </Provider> //생략 가능 
  </React.StrictMode>
);

이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?

위에 과제를 하면서 내가 알게된 점, 좋았던 점 내용에 적혀 있는 부분들을 사실 가장 신경 쓰며 진행을 했기 때문에 알게 되었고, 좋았던 부분들이기도 한 내용인데

  • models > hooks > components 로 계층을 분리
  • 그 구조에 맞게 파일 및 코드 끼워 넣기

에 가장 신경을 많이 썼습니다.

추가적으로 네이밍 컨벤션에도 생각보다 많은 고민을 하기도 했었습니다.

  • 상태: xxxAtom
  • 훅: useXxx
  • 컴포넌트: PascalCase
  • 함수: camelCase

의 규칙을 지키도록 했습니다!

테스트 코드도 기본적으로 Commit 하기 전에는 언제나 통과되는 기준으로 가고자 했는데 중간 중간 미흡하게 커밋한 흔적이 있습니다. 이 부분은 의식하며 앞으로 업무를 할 때 체크 해야 된다고 생각이 들었습니다.


이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!

회사 솔루션 코드에 적용 할 수 있는 부분 고민해서 Jotai 도입 빌드업 하기

현재 사내 솔루션에는 Zustand를 사용하고 있습니다. Jotai는 사용해 보니 규모가 큰 프로젝트에서는 한 곳에서 관리하는 부분이 어려워서 솔루션에 적용은 어렵겠지만 정부과제나 경량형으로 나가는 솔루션 패키지에 적용 해 보고 싶은 생각이 들었습니다.

디자인 패턴 공부

발제 시간에도 설명 해 주셨던 내용인 부분이고 https://refactoring.guru/design-patterns 사이트 및 발제자료 등을 참고하여 근본이 되는 23가지 패턴과 프론트엔드에서 의미하는 디자인 패턴을 문서화하여 나의 지식으로 쌓을 것입니다.


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

  1. 실무에서 이런 대규모 리팩토링을 진행할 때 이번 과제처럼 나 혼자 하는 것이 아닌 경우가 대부분 일텐데
    • 어떤 순서와 전략?방법?을 사용하시나요?
    • 팀원들과의 협업 방법은 어떻게 하시나요?

마지막으로 이번 과제를 하면서 특히 6팀 김원표 항해메이트님께서 많은 리뷰와 가이드를 해주었습니다. 직접 항해 일지에 어떤 것을 하면 좋을지도 적어주고 코어 타임 시간에 화면 공유를 통해 구조 리뷰 및 어떤 부분을 리팩토링, 구조변경을 하면 어려움이 없을 지에 대해 고민하여 가이드 해주고 가장 고마웠던 부분은 처음 App.tsx 파일을 열었을 때 초기 데이터만 분리하고 시작을 못 하고 있을 때 헤매면서 hooks 분리를 먼저 시작하고 있었는데 "먼저 화면을 보고 화면상 어떤 부분을 나누면 좋을지, 그래서 Cart 화면과 Admin 화면을 일단 App에서 분리를 하고 진행을 해보자" 등 중간 중간 지속적인 방향성을 잡아 주었습니다.

shout out to "김원표"

  • 항해 일지에 피드백 및 어떤 부분 오늘하면 좋을지 혹은 의논 예정 내용까지 적어주었습니다 Good image

과제 피드백

안녕하세요 태영, 수고했습니다! 이번 과제는 React의 Custom Hook 개념을 이해하고 함수형 프로그래밍의 순수함수 개념을 체득하면서 적절한 계층 분리를 경험하는 것이 목표였어요.

"순서가 중요하다!!!!"라는 깨달음 좋습니다. 실제로 리팩토링에서 가장 많이 실수하는 부분이 바로 순서죠. icons를 먼저 분리하지 않고 진행했다가 svg 코드들을 다시 찾아 헤맨 경험 - 이런 시행착오가 진짜 학습이죠. 리팩토링을 할때에는 작은 것 부터 그냥 하면 100% 나아지는 게 확실한 소소한 것들을 하는게 중요합니다. 구조보다도 분리가 가능한 클린한 코드로 야금야금 만들어두는거죠. svg를 icon으로 만든다거나 좋지 않은 이름을 바꾼다거나 inline 핸들러를 옮긴다거나 코드의 순서를 정돈한다거나 주석을 다는 일처럼 말이죠.

또 models > hooks > components의 단방향 데이터 흐름이라는 의미를 몸으로 느낌을 이해한듯 해서 좋네요. 데이터의 흐름을 이해하면 그 흐름은 그대로이면서 세부 계층이 더 쪼개어지는 거라 model의 타입 - 원본데이터 - 파생 데이터 등으로 쪼개어지고 hook도 그렇고 component도 세부적인 단계로 쪼개어질 수 있다는걸 느낄 수 있을거에요!

Q) 실무에서 대규모 리팩토링을 진행할 때의 순서와 전략 => 큰 방향과 목표에 대해서 공감대를 항상 갖추고 컨벤션을 갖추려하지만 이걸 작정하고 대대적으로 수정하거나 하지는 않아요. 규모가 클수록 기존의 동작이 문제없을거라는 재검증을 하는데 엄청난 에너지가 들기 떄문에 - 다시 다 확인해야하는 것인 만큼 - 그래도 평소에 조금씩 분리가능한 구조 즉 결합도를 낮춰두는 구조를 유지하는게 중요합니다.

=> 해보면 알겠지만 결합도가 충분히 낮은 좋은 구조를 가지고 있으면 그 뒤에 어떻게 재배치를 하거나 이전하는것이 어렵지 않을 뿐더라 문제가 생기는 경우도 굉장히 낮거든요. 그렇기 때문에 소소하게 조금씩 더러운 곳을 치워나가는 습관이 제일 중요합니다.

=> 그렇게 코드가 갖춰져 있다면 규모에 맞춰 응집도를 더 좋게 할 수 있는 적절한 구조들에서 대해서 열심히 고민하고 상의해보면서 실험등을 통해 합의를 하게 되겠죠. 테스트 코드도 작성하고 커버리지도 확인하면서 말이죠.

Q) 팀원들과의 협업 방법

=> 리팩토링 전에 팀 전체가 목표와 방향성을 공유하는 게 핵심이에요. 우선 당연히 해야하는 것들에 대해서도 합의가 있으면 좋아요. svg는 IconOOO 형태로 옮겨둔다라거나 하면 안되는 안티코드들.

그런데 폴더구조라건다 새로운 기술 스택의 도입등은 모두에게 영향을 미치는 만큼 충분한 합의가 필요합니다. 어떻게 구체적으로 할지를 정하는게 아니라 더 큰 합의. 왜 하려고 하는지 원하고자 하는게 무엇인지 결정은 어떻게 할 것인지 이런것들의 합의를 충분히 하면 고민이 생겼을때 그 합의했던 내용을 바탕으로 결정을 할 수 있답니다.

수고하셨습니다. 6주차 과제도 화이팅입니다