컴포넌트 개발 규칙 설정하기

이번 글에서는 현재 진행하고 있는 사이드 프로젝트의 컴포넌트 개발 규칙을 설정해 보고자 한다.

프로젝트의 초반 단계에서 어떤 규칙을 가져갈 것인지 결정하는 것은 무척 중요하다.

지난 개발 경험에서 느낀 문제점들을 개선할 수 있도록 고민한 규칙들을 정리해보고자 한다.

 

[문제점]

- 컴포넌트는 사용자 UI와 직접적으로 맞닿아있는 부분이고 변경사항도 잦다. 그때그때 필요할 때마다 덧붙이듯 개발을 진행한 결과, 일관성이 없고 코드를 모두 읽어봐야 파악할 수 있게 되었다. 일관된 규칙이 없기 때문에 확장성도 매우 떨어진다. 

- 코드를 수정할 때, 기존 코드가 제대로 작동하는지를 보장할 수 없다.

 

[개선 방향]

- 어떻게하면 확장성을 향상할 수 있을까? 이러한 규칙을 정하면 이를 지키면서 일관성도 얻을 수 있다. 

- 코드를 수정할 때, 기존 코드가 제대로 작동하는지를 보장할 수 있는 장치를 추가한다.

 

다양한 컴포넌트 설계 방법론들을 검색하고 알아가는 과정을 통해 많은 지식공유자 분들이 공유해주신 좋은 방법들을 발견했다. 그중 Jbee님께서 공유해주신 변경에 유연한 컴포넌트라는 포스팅에서 좋은 인사이트를 얻게 되었고, 해당 내용을 적극적으로 도입해보고 싶어 원작자님께 허락을 받고 도입과 블로깅까지 진행하게 되었다. 흔쾌히 허락해주신 Jbee님께 감사인사를 드립니다:)

 

확장성은 무엇일까? 변경에 유연한 컴포넌트 글에서 소프트웨어는 지속가능하고 예상할 수 없는 변경에 그나마 유연하게 대응할 수 있어야 한다고 말한다. 컴포넌트가 확장성을 가진다는 것은 무엇일까? UI를 결정짓는 요소들은 정말 많은데, 이러한 요소들이 변경될 때 컴포넌트가 일관성을 유지할수 있는 것이다. (보다 다양한 변경에도 컴포넌트를 재사용할수 있게 됨) 그렇다면 컴포넌트가 가져야할 일관성이란 무엇일까? 컴포넌트가 설계된 본래 의도를 잘 유지한다는 것이고, 이를 바꿔말하면 컴포넌트를 설계할때부터 명확한 의도와, 이를 유지할 수 있는 장치를 마련해 주어야 한다는 것일 수도 있겠다. 위에 언급한 글에서는 공통 컴포넌트에서 도메인 맥락을 제거하고 UI를 기반으로 추상화하며, 일반적인 인터페이스로 컴포넌트를 디자인할 것을 제안하고 있다. 이 내용을 바탕으로 이번 프로젝트에서 컴포넌트를 개발할 때 이루고 싶은 목표를 정리해봤다.

 

[목표]

1. TDD 도입

  - 목적: 완벽한 통합 테스트x. 유닛 테스트 기반으로 실패 -> 성공 -> 리팩토링의 절차대로 개발해 보기

             단위 테스트를 통해 컴포넌트의 의도를 명확히 밝혀보기

2. 컴포넌트 설계 목표 -1: [공통 컴포넌트] UI 우선 단위 정의

  - 컴포넌트의 이름과 props는 외부로 제공하는 인터페이스라는 것을 생각하여 내부 캡슐화가 잘 구현되도록 하기

3. 컴포넌트 설계 목표 -2: 데이터 기반(DB 모델 조각 기준) 컴포넌트 

  - 도메인 종속적이고 재사용이 잦은 코드는 DB 필드를 기반으로 타입을 지정하고, 작은 조각으로 나누어 모듈화한다.

 

[세부목표]

1. UI기반의 컴포넌트

우선 UI를 기반으로 어떻게 보여질 것인지를 정의하고, 이를 드러낼수 있는 이름과 props를 정의한다.

내부 구현은 컴포넌트 합성을 통하고, 데이터 기반의 컴포넌트를 조합하는 방식으로 재사용한다. 

Dom attribute를 참조하여 제공할 꾸러미를 정의한다.

2. 데이터 기반의 컴포넌트

도메인 정보를 가진 데이터는 DB 모델에 기반해서 타입으로 정의한다. 이 타입을 기준으로 작은 단위로 쪼갠 데이터 기반의 컴포넌트 꾸러미를 가지고 이를 조합하여 활용하도록 한다. 이 컴포넌트들은 modules에 도메인 이름별로 폴더를 만들어 관리하려고 한다. 

3. 스타일은 어떻게 할것인가

utility first css스타일에 매력을 느껴 tailwind를 채택했다. 클래스명을 조합하는 방식으로 컴포넌트를 제공하는 flowbite의 방식이 DOM attribute를 살리는 현재 방향과 잘 맞는다고 생각되어 flowbite를 도입한다. 길어지는 클래스명은 styled component에 위임한다.

4. 데이터는 어떻게 할것인가

Next.js 기반으로 프로젝트를 진행했기 때문에 pages내 파일들은 도메인 데이터를 가지게된다. 이 데이터를 데이터 기반 컴포넌트에 props 형태로 전달하고, 이 컴포넌트들을 합성하여 UI 기반 컴포넌트의 내부 구현체를 완성한다.

5. 폴더 구조

/components
	/... UI 기반의 컴포넌트들
    /modules
    	/... 데이터 기반의 컴포넌트들
        /domain name
        	/... 해당 도메인 데이터 기반의 컴포넌트들
            
/pages
/type
	/domain name -> 해당 도메인 내 데이터 타입 정의

 

[Action Item 정리!]

1. 컴포넌트를 설계할 때 이 컴포넌트가 어떻게 사용되어야 하는지 먼저 정의한다.

2. UI요소와 데이터 기반 요소를 정리하고 분리하여 각각의 컴포넌트로 구성한다.

3. 컴포넌트의 의도를 정의하고 이를 검증할수 있는 테스트 케이스를 작성한다.

4. 테스트 케이스를 통과할 수 있는 컴포넌트를 작성한다.

5. 컴포넌트를 리팩토링하며 정리한다.

 

다음 글에서는 실제로 이와 같은 방식으로 컴포넌트를 개발해 보려고 한다!