요새 UI 컴포넌트 개발 업무를 주로 수행하고 있다.
SI 회사에 재직중이다 보니, 단기간에 꽤 많은 양의 컴포넌트를 기계적으로 뽑아내야 한다
점점, 살아있는 컴포넌트 생산 공장이 되어가고 있다.
사용성(DX)와 확장성, 유지보수성을 고려한 컴포넌트를 개발하는 것은 어렵다.
특히 단기간에 더 많은 개발 업무를 수행해야 한다면,
DRY(Don'y Repeat Yourself) 원칙을 준수하는것도 점점 어려워지게 된다.
(사실 요즘 더 관심있는 분야는 Devops, Web Automation, Test 분야인데, 컴포넌트 쳐내기만 급급하다)
그럼에도 불구하고, 컴포넌트 내에서 질서를 뽑아낼 수는 있다.
개인적으로 자주 방문하는 카카오 엔터테인먼트 기술 블로그에는 React 컴포넌트와 추상화
라는 좋은 글이 있다.
또한 스토리북 작성을 통해 얻게 되는 리팩토링 효과
라글도 아주 좋은데, 이 두 게시물의 차이점은 로직 관심사, 스타일 관심사 관점에서 컴포넌트를 설명한다는 것이다.
즉, 컴포넌트의 단위 지정은 비즈니스 로직 뿐만 아니라 스타일 관심사도 고려해야 한다는 것이다.
그렇다면 스타일 관심사의 단일 진실 원천은 무엇인가?
바로 피그마 파일이다.
도메인 주도 설계를 위해선 비즈니스를 이해할 필요가 있다.
UI 컴포넌트를 이해하기 위해선 디자이너들의 디자인 디시전을 이해할 필요가 있다.
UI 컴포넌트의 API는 디자인 관심사를 반영해야 한다.
이는 반대로 디자인 파일이 원칙이 없고 부실하면, 좋은 컴포넌트가 나오기 어렵다는 말이 된다. (-_-)
도메인 주도 설계를 위해 현업 담당자들과 소통하듯,
UI 컴포넌트를 잘 이해하기 위해선 UI의 도메인 언어인 디자인에 대해 어느 정도 이해할 필요가 있다.
또한 피그마 파일;도메인이 부실한 상황에서도 꽃울 피우기 위해서도다.
개발자와 디자이너의 API 공동 설계를 다룬 글
그러면 자주 등장하는 단어인 variant, design token 등에 익숙해지게 되고,
UI 관점에서 더 적절한 API를 도출해 낼 수 있게 된다.
아토믹 디자인 패턴을 들어본 적이 있을 것이다.
사실 아토믹 디자인 패턴은 개발자가 컴포넌트를 만들기 위한 패턴이 아니라,
디자이너들이 디자인을 하기 위한 방법론이다.
하지만 우리는 해당 방법을 개발에서도 적용하고 있다.
이는 디자인의 사상과 컴포넌트 설계 사상이 크게 다르지 않은 것을 의미한다.
또한 아토믹 디자인 패턴에서 중요한 단위는 Template다.
탬플릿은 Placeholder 만을 갖고 있다.
실제 데이터 인스턴스가 속을 채워 구체화한 결과는 Page다.
리액트 관점에서 Template는 프리젠테이션 컴포넌트 조합이고
Page는 컨테이너 컴포넌트 조합이라 할 수 있겠다.
디자인시스템, UI 개발자로서는 Template 이하의 관심사에 집중할 필요가 있겠다.
JSON 상하차 관점(...) 에서는 Pages 관심사에만 집중하면 된다.
각각은 스타일,레이아웃과 비즈니스 로직을 의미하며, 각 관심사가 분리되어야 함을 나타낸다.
Template 이하의 관심사는, 마크업과 스타일의 재사용성을 극대화하여 합성하는 방법일 것이다.
다음 번에는 이를 위한 합성 방법에 대해 이야기해보도록 하겠다.
본인이 운영하는 별도 블로그에 이미 관련 내용이 있긴 하다.
