211001(금) - 컴포넌트 디렉터리 구조 변경

목차

• 컴포넌트 디렉터리 구조 변경
  • 문제의식
  • 목표
  • 기준
  • 리팩터링 진행
  • 결과

컴포넌트 디렉터리 구조 변경

프로젝트를 시작하면서 컴포넌트 디렉터리 구조에 대해 페어와 많은 이야기를 나눴지만 우리 프로젝트에 어떤 구조가 잘 들어맞는다라는 것을 찾지 못해, 계속 고민을 해보자며 보류하고 있었다. 특별한 변경 없이 components 폴더 안에 컴포넌트를 추가해 갔는데, 도메인에 상관없이 사용될 수 있는 컴포넌트와 우리 도메인의 성격을 띤 컴포넌트로 나눌 수 있어서 common 폴더만 따로 분리한 상태였다. 현재 디렉터리 구조는 다음과 같은 형태다.

문제의식

확실히 컴포넌트 개수가 많아지니, 한눈에 찾기는 쉽지 않았다. 하지만, 프로젝트를 진행하면서 컴포넌트의 이름은 파악하고 있고, 컴포넌트도 cmd + p로 검색했기 때문에 크게 불편한 점은 없었다. 그런데 현재 구조의 문제가 있음을 최근에 느끼게 되었다. 요즘은 예전처럼 프로젝트를 계속 붙잡고 있지 않다 보니 컴포넌트 이름이 한 번에 잘 생각나지 않았고, 자연스레 디렉터리를 보면서 찾는데 그게 쉽지 않았다. 프로젝트 개발을 처음부터 해왔는데도 이 정도이면 문제라곤 생각했고 미뤄왔던 컴포넌트 디렉터리 구조 변경 리팩토링을 시작했다.

목표

목표는 '새로운 개발자가 투입되었을 때, 쉽게 이해할 수 있는 디렉터리 구조'였다. 현재 프로젝트에서는 인원이 추가될 일이 없지만, 현업에서는 인원 변경 가능성이 있다고 생각해 목표를 다음과 같이 설정했다.

기준

컴포넌트를 나눌 기준으로 관계성, 컴포넌트의 위치 등의 의견이 나왔다. 컴포넌트 자체가 재사용성을 위한 개념이기 때문에 사용되는 컴포넌트의 위치로는 기준을 정할 수 없었다. 다만 관계성을 생각해 봤을 때는 어느 정도 이해가 됐는데, 의미가 워낙 포괄적이라 common 폴더에서 사용되는 것을 제외하고 서로 엮여있는으로 기준을 설정했다. 엮여있다는 단어를 페어와 나는 의견을 나누면서 이해했지만, 단어가 그 의미를 완벽하게 전달하는 것은 아니어서 풀어쓰자면 관계성을 지니면서 해당 컴포넌트에서 사용되는 컴포넌트 정도인 것 같다.

기준을 세우면서 들었던 생각은 '컴포넌트를 나누는데 정량적인 기준을 세우는 것은 불가능한가'였다. 누가 봐도 이해할 수 있는 수치화된 기준으로 나누고 싶었는데, 컴포넌트의 재사용성, 확장성 등을 고려하면 그건 불가능하다는 생각이 들었다. 컴포넌트가 어디에서 사용될지, 어떻게 합성되어 구성될지 모르기 때문이다. 나름 패턴이 된 아토믹 디자인 패턴도 이런 점에서 우리 프로젝트의 기준이 될 수 없다고 생각했다.

리팩터링 진행

완벽히 정량화된 기준은 아니지만, 어쩔 수 없는 부분이라 생각하고 리팩토링을 진행했다. common은 그대로 유지했고, 크게 comment, review, preview, statistics로 구분했다. comment는 게시글의 댓글 관련 컴포넌트, review는 우리 프로젝트에서 게시글과 관련된 컴포넌트고, preview는 홈페이지나 마이페이지에서 내가 쓴 댓글의 페이지에서 보이는 글을 요약한 미리 ㄴ보기 관련 컴포넌트다. 마지막으로 statistics는 차트, 표, 그래프 등 통계 관련 컴포넌트다.

리팩토링을 하면서 주로 시간을 쏟은 부분은 두 곳이다. 먼저 statistics에 속해있는 VaccinationSymptom 컴포넌트와 PreviewItem, ReviewItem 컴포넌트 부분이다.

첫 번째 이슈는 이전에 HomeContent라고 불리던 컴포넌트였다.

홈페이지에서 오른쪽에 위치하고 있는 차트와 아래 링크 버튼을 포함한 컴포넌트인데, 이 컴포넌트의 문제점은 역할이었다. 해당 컴포넌트 내에 그래프와 링크 버튼이 있는데, 이름은 또 HomeContent라고 되어 있어 컴포넌트 특성을 온전히 담아내지 못하고 있었다. 이런 컴포넌트가 탄생한 이유는 HomePage 컴포넌트의 간결성을 위해서였는데, 간결성을 위해서 컴포넌트 네이밍, 역할 등 놓치는 게 많아 수정이 필요했다. 리팩토링으로 컴포넌트의 링크 버튼들을 분리하여 HomePage 컴포넌트에 그대로 써주고, 컴포넌트 이름을 증상 통계만 나타내도록 VaccinationSymptom으로 변경했다. 이렇게 수정하니, 컴포넌트를 분리하면서 만들었던 네 개의 카테고리 중에서 statistics에 포함될 수 있었다.

두 번째 이슈는 previewItem, reviewItem 컴포넌트였다.

위의 세 개 컴포넌트는 각각 홈페이지에서 보여주는 PreviewItem, 마이 페이지 내가 쓴 댓글 페이지에서 보여주는 MyCommentsItem, 후기 페이지에서 보여주는 ReviewItem이다. 리팩토링을 위해서 네 가지 목록을 정하면서, MyCommentsItem이 길을 잃게 되었는데, 마침 세 개의 형태가 비슷하다 보니 하나의 컴포넌트에 타입을 구분해서 만들면 되겠다고 생각했다. 하지만, 왼쪽 상단 백신 티켓 크기, 이미지 포함 여부, (위 사진에서는 확인이 되지 않지만) 보이는 글의 수 등 타입으로 할 경우 조정해야 할 부분이 많아 분리하기로 결정했다. MyCommentsItem은 PreviewItem과 사진 포함 유무만 제외하고 거의 비슷해서 PreviewItem에서 prop으로 이미지 받는 것을 추가해 대체했고, 해당 컴포넌트를 삭제했다.

결과

리팩토링을 통해 얻은 점 중 가장 큰 부분은 서로 엮여있는 컴포넌트를 쉽게 확인할 수 있게 된 점이다. 학교 다닐 때 UX 수업에서 배웠던 입도를 대입해 보면, review가 다른 분류 항목에 비해 조금 크다고 느껴지고, 컴포넌트 분류 기준이 완벽히 정량적이지 않아(사실 이게 정량적으로 되는지도 모르겠다) 아쉬운 부분도 있지만, 충분한 성과라는 생각이 든다. 추가적으로 common을 최상단에 두어 가독성을 높이기 위해 @을 붙였다(이름을 변경하다 yarn.lock 파일도 한꺼번에 바꿔버려 찾는데 고생 좀 할 뻔하다가 곧 찾았다 휴).

이제 이런 컴포넌트 구조면 우리 프로젝트에 새로 추가되는 개발자가 쉽게 이해할 수 있으려나?