리팩터링을 하면서 피부로 느낀 작은 컴포넌트의 필요성

 

오늘 진행했던 주요 작업 중의 하나로 값 객체로 임시로 사용하고 있던 장소(Place) 객체를 Entity로 승격시키고, 그 과정에서 발생하는 타입 불일치 에러를 잡으면서 장소 기능을 사용하고 있던 게시글 목록 조회, 게시글 상세 정보 목록 조회, 게시글 작성 기능이 이전과 같이 작동하게 하는 작업이 있었다.

 

지금까지는 장소 객체를 그냥 텍스트와 다를 바 없이 사용하고 있었지만, 관리자 페이지에서 등록된 장소를 조회하거나 추가, 삭제할 수 있는 기능을 추가하면서 장소가 가져야 할 내용이 세분화될 필요성이 생겨 리팩터링을 진행했다.

 

백엔드 리팩터링은 PlaceRepository를 추가해 장소 데이터를 가져와야 하는 Service 레이어에서 인스턴스를 꺼내오고, 시그니쳐가 바뀌면서 발생하는 에러는 이제는 적절히 잘 추적해 어렵지 않게 오류를 잡을 수 있었다.

 

다만 이번 작업은 백엔드 리팩터링뿐만 아니라 프론트엔드 리팩터링도 같이 진행해야 하는 작업이었다. 장소 객체가 독립적인 객체가 되면서, 서버에서 클라이언트로 보내는 DTO에서 장소 객체를 구체적으로 나타내줘야 하면서 주고받는 데이터의 양식이 바뀌게 되었다.

 

게시글 목록 조회 시에는 목록에서 개별 게시물의 썸네일 하나를 나타내는 PlaceListDto에 PlaceListDto가 중첩되어 추가로 전달되게 되었고, 게시글 상세 내용 조회 시에는 장소 데이터 fetch를 별도로 요청해 가져오는 로직이 추가되게 되었다. 이처럼 주고받는 데이터의 양식이 수정되면서 기존의 양식에 맞춰 데이터를 가져오던 Store와, Store의 상태를 참조하고 있는 페이지 컴포넌트, 페이지 컴포넌트로부터 상태를 전달받는 UI 컴포넌트 모두가 수정되어야 했다.

 

프론트엔드를 수정하는 과정에서 며칠 전에 느꼈던 UI 컴포넌트들을 각 컴포넌트가 나타내려는 리소스의 조합을 기준으로 작게 나누고, 해당 컴포넌트에서 Store를 직접 참조하게 하는 식으로 개별 컴포넌트의 크기를 줄이는 방식으로 리팩터링을 해야 할 필요성이 강하게 느껴졌다.

 

페이지 컴포넌트에서 Store의 모든 데이터와 함수를 참조해 UI 컴포넌트에 내려주는 지금 구조에서는 내용이 조금 바뀌었을 뿐인데도 컴포넌트 간에 주고받는 20줄 가까이 되는 prop들 사이에서 어떤 부분을 추가하거나 바꿔야 하는지 힘들게 찾아야 했다. 테스트 코드에도 너무 많은 데이터 세팅과 prop이 있어 고치는 데 무시무시한 시간이 걸렸다.

 

좋은 구조의 코드만을 보고 학습할 때는 '이걸 이렇게까지 분리해야 해?' 싶은 느낌이었는데, 안 좋은 코드를 짜면서 고통을 받아보니 '이래서 분리를 해야 하는구나'가 피부에 각인되는 느낌이다.

 

 

 

작업 내역

프론트엔드

- https://github.com/hsjkdss228/smash-frontend/pull/51 (DTO 및 모델 구조 변화에 따른 기존 기능 동작 리팩터링)

백엔드

- https://github.com/hsjkdss228/smash-backend/pull/35 (Place 값 객체를 Entity로 승격, 장소 목록, 개별 장소 상세 내용 요청 처리)