[13팀 최서은] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍 #53
Open
choiseoeun-GoUp wants to merge 6 commits intohanghae-plus:mainfrom
Open
[13팀 최서은] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍 #53choiseoeun-GoUp wants to merge 6 commits intohanghae-plus:mainfrom
choiseoeun-GoUp wants to merge 6 commits intohanghae-plus:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
과제의 핵심취지
과제에서 꼭 알아가길 바라는 점
기본과제
Component에서 비즈니스 로직을 분리하기
비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기
뷰데이터와 엔티티데이터의 분리에 대한 이해
entities -> features -> UI 계층에 대한 이해
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
특정 Entitiy만 다루는 함수는 분리되어 있나요?
특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?
데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?
심화과제
재사용 가능한 Custom UI 컴포넌트를 만들어 보기
재사용 가능한 Custom 라이브러리 Hook을 만들어 보기
재사용 가능한 Custom 유틸 함수를 만들어 보기
그래서 엔티티와는 어떤 다른 계층적 특징을 가지는지 이해하기
UI 컴포넌트 계층과 엔티티 컴포넌트의 계층의 성격이 다르다는 것을 이해하고 적용했는가?
엔티티 Hook과 라이브러리 훅과의 계층의 성격이 다르다는 것을 이해하고 적용했는가?
엔티티 순수함수와 유틸리티 함수의 계층의 성격이 다르다는 것을 이해하고 적용했는가?
과제 셀프회고
과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?
이번 클린코드 과제를 하면서 가장 신경 썼던 건 코드를 좀 더 읽기 쉽게 만들고, 구조적으로 나누는 작업이었습니다. 특히 변수명이나 함수명을 볼 때마다 “이 이름만 보고 역할이 바로 이해될까?”라는 기준으로 체크했고, 중복되거나 과하게 긴 로직은 최대한 정리해서 단일 책임을 가진 코드로 나누려고 했습니다.
그 외에도 UI 로직과 상태 관리, 실행 결과 처리 같은 기능들을 분리해서 기능별 훅으로 나누는 작업을 많이 했고, 전체 흐름이 조금 더 명확하게 드러나도록 구조에 신경 썼습니다.
과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?
이번 과제를 다시 하게 된다면, 몇 가지 아쉬웠던 부분은 확실히 보완하고 싶습니다.
먼저, 컴포넌트 분리를 좀 더 적극적으로 하지 못했던 게 아쉬웠습니다. 중첩되거나 복잡한 UI 구조를 더 잘게 나눌 수 있었는데, 시간이 부족하다 보니 몇몇 부분은 그대로 두게 됐고, 그 결과 일부 로직이 여전히 한 컴포넌트에 너무 많이 몰려 있었던 것 같습니다. 그리고 훅 분리도 더 할 수 있었는데, 일부 기능은 그대로 남아 있어서 구조적으로 아쉬움이 남았고, 무엇보다 아쉬웠던 건 훅이나 컴포넌트를 나눈 후에 테스트 코드를 제대로 작성하지 못했다는 점입니다.
분리한 훅과 컴포넌트들이 제대로 작동하는지, 변경해도 깨지지 않는지 확인할 수 있는 테스트가 있었으면 나중에 리팩토링이나 기능 추가할 때 훨씬 자신감 있게 작업할 수 있었을 텐데, 그 부분이 많이 부족했습니다.
이번 과제를 하면서 코드 구조나 네이밍 같은 정적인 부분은 많이 신경 썼지만, 테스트 코드까지 연결해서 안정성과 유지보수성까지 챙기지 못한 점이 제일 큰 아쉬움으로 남았습니다. 다음 과제나 실무에서는 구조 설계와 테스트 작성이 같이 갈 수 있도록 더 준비하고 접근해보려고 합니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
사내 제품에서 특정 페이지 기능을 리팩토링하며 로직들을 여러 커스텀 훅으로 분리했습니다. 각 기능 별로 분리해서 관리하고 있지만 점점 훅끼리 서로 상태나 함수를 주고받다 보니 결합도가 높아지고, 훅 하나를 바꾸면 다른 훅에도 영향이 생기는 구조가 됐습니다. 이런 경우 훅을 잘못 나눈 걸까요? 혹은 이런 의존 관계가 발생했을 때는 하나로 통합하거나 구조를 다시 묶는 게 더 나은 방향일지 고민이 됩니다.
훅을 설계할 때 어떤 기준으로 분리/통합을 판단하는 게 좋을지 조언 부탁드립니다.