훅 추상화 강도

전 추상화가 강하게 된 훅으로 빼서 재사용하는 걸 좋아했습니다. 처음에는 멋진 추상화를 만들어서 만족하지만, 시간이 지나면서 기획이 바뀌고 새로운 요구사항이 생길 때마다 그 추상화가 발목을 잡는 경험을 하게 되었습니다
 
최근 URL 파라미터와 연동된 테이블 필터 훅을 구현하면서 이런 딜레마를 겪고 추상화 강도에 대한 이 바뀌게 되었습니다

문제 상황

처음에는 URL 파라미터 연동, 필터 상태 관리, 초기화 등 모든 것을 한 번에 처리하는 테이블 필터 추상화 훅을 만들었습니다. 비즈니스로직을 잘 분리할 수 있어서 매우 만족스러웠습니다.
하지만 현실은...
 
기획 변경 1: 테이블 외부 날짜 선택기(date picker)도 연동
기획 변경 2: 필터 초기값 지정
기획 변경 3: 날짜 필터는 다른 필터 초기화할 때 유지되어야 함
각각의 요구사항마다 복잡한 설정 옵션을 추가하거나, 타 페이지 영향 없이 처리하기 위해 어댑터 패턴으로 우회하는 코드가 필요했습니다.

깨달음

이 과정에서 깨달은 핵심은 추상화 수준을 아토믹하게 두어야 한다는 것이었습니다.
기존에 제가 만든 훅은 너무 많은 책임을 가지고 있었습니다:

• URL 파라미터 필터 동기화
• 필터 수정
• 초기값 적용

이 모든 것을 하나의 훅에서 처리해 재사용하려다 보니, 하나의 요구사항이 바뀔 때마다 전체 구조를 수정해야 했습니다.

해결책

리팩토링을 위해 산정된 일정을 호다닥 완료하고 기존 코드를 대폭 리팩터링 했습니다. 핵심은 정말 변하지 않는 최소한의 책임만 훅으로 분리하는 것이었습니다.
1. URL 필터 동기화만 담당하는 훅

• 오직 URL 파라미터 읽기/쓰기만 처리
• 어떤 데이터를 다루는지는 신경쓰지 않음

2. 날짜 범위 처리만 담당하는 훅

• 날짜 검증과 포맷팅만 처리
• URL이나 다른 상태와는 독립적

3. 나머지는 단순 함수로 상황에 맞게 사용

페이지별 조합

이제 각 페이지에서는 모든 옵션이 커버되는 고수준 추상화 필터 훅 대신 필요한 아토믹 훅들을 조합해서 사용합니다:

• 기관 관리: 필터 URL 동기화 + 클라이언트사이드 필터 + 전체 like search 훅
• 재무 관리: 필터 URL 동기화 + 서버사이드 필터 + date range + 페이지네이션 훅
• 이슈 관리: 필터 URL 동기화 + 서버사이드 필터 + 무한스크롤 훅
• 사용자 관리: 필터 URL 동기화 + 서버사이드 필터 + 권한 파싱 어댑터 유틸 함수

기획이 바뀌면? 해당 페이지의 조합만 수정하면 됩니다.

핵심

이번 경험을 통해 가독성보다 유지보수성을 더 우선시하게 되었습니다
전 천재가 아니고 경험도 요만한 주니어라 모든 변경을 예측할 수 없으니까요..

과거의 나

• 모든 요구사항을 최대한 예측해서 *3단계로 강하게 추상화 (ex. useFilterManager)
• 비즈니스 로직, 애플리케이션 로직, UI을 완전히 분리해 이해하기 쉬운 코드 지향
• 한 번 만들면 여러곳에서 재사용 가능한 라이브러리 같은 코드 지향

현재의 나

• 단일 책임원칙 강하게 준수해 *1,2단계 훅의 조합 위주로 추상화
• 조금 섞이더라도 의존성 적은 코드 지향
• 변경이 잦은 상황에 맞게 조합 가능한 코드 지향

*https://junilhwang.github.io/TIL/clean-code/조각모음/추상화를-정렬하기/#마무리

추상화를 정렬하기 | 리액트 클린코드

 
 

마무리

이전에는 한 번에 보고 테마별로 묶인 고수준 추상화를 지향했다면,
지금은 아토믹한 추상화를 기반으로, 필요할 때마다 계층적으로 쌓아 올리는 방식을 더 선호합니다.
앞으로는 “이 코드가 얼마나 가독성이 좋은가?”보다 “이 코드를 6개월 뒤에 수정하거나 버리기 얼마나 쉬울까?”를 더 중요하게 생각하려 합니다.
 
추상화 정도 관련으로 사내 프론트 스터디에서 많은 토론을 했었는데 역시 직접 겪어보니까 생각이 확 바뀌네요
귀찮아하지 않고 관련 이야기 맨날 들어주신 지미 잭슨께 압도적 감사..
 
근데 걍 더 설계 잘해지고 경험 늘면 될 수도 있지 않을까..! 또 스타일 바뀔 수도 있음
 
이 글에서 메서드 전문화가 공감이 많이 되는 부분.. https://kciter.so/posts/the-aesthetics-of-destroying-software/#%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A0%84%EB%AC%B8%ED%99%94

소프트웨어 파괴의 미학