디자인 시스템: 구성 요소의 조합 철학

하나의 큰 조직에서 제품이 신속하게 발전하기 때문에 회사는 신속하게 행동하고 지속적으로 신제품을 구축하고 납품하며 기존 제품을 유지해야 한다.이 모든 것의 일부로서 채택된 해결 방안은 흔히 볼 수 있는 도안, 색깔, 레이아웃과 격자에 뿌리를 둔 디자인 시스템을 구축하는 것이다.
디자인 시스템을 구성 요소로 구체화한 팀에게 가장 큰 도전은 회사의 신속한 발전을 보여주고 제품 팀에게 구성 요소 가치를 계속 제공하는 것이다.한 조직의 개발자는 제품이 끊임없이 발전하고 있기 때문에 실현을 초월하기를 희망하지만, 그들 중 일부는 실현만을 따르려고 한다.
이러한 환경에서 매우 큰 도전이 있다. 디자인 분야의 디자인 시스템 팀은 서로 다른 방법을 취해 디자인을 특정한 구성 요소 사례에 제한하거나 기초(예를 들어 색깔, 레이아웃, 간격, 격자, 레이아웃...)만 만들 수 있다.아니면 이 두 가지 상황을 동시에 만족시킬 수도 있다.모든 상황은 결점과 장점이 있기 때문에, 당신은 모든 상황이 어떻게 당신의 조직 환경에서 더욱 잘 일하는지 이해해야 한다.
다른 한편, 구성 요소 라이브러리의 개발자는 다른 방법을 취할 수 있다.

디자인 시스템 사례만 제공하는 구성 요소를 만들고 구성 요소의 사용을 정의된 사례 이외의 다른 사례로 제한한다.

고도의 유연성을 가진 구성 요소를 생성하여 개발자가 제품 설계가 정의를 초과할 때 정의에서 벗어날 수 있도록 한다.

이렇게 하는 결과는 쌍방에 좋지 않을 수도 있다. 우리는 개발자를 낙담하게 할 수도 있다. 왜냐하면 그들은 자신의 구성 요소를 만들어야 하거나 유연한 구성 요소를 사용하여 대량의 작업을 해서 팀의 디자이너가 만든 디자인의 구체적인 상황을 달성해야 하기 때문이다. 디자인 시스템은 디자이너의 창조적인 사고를 방해할 수 있다. 왜냐하면 구성 요소의 정의가 고정적이기 때문이다.
이 점을 바로잡고 처리하는 것은 매우 복잡하지만, 우리는 어떻게 해야 합니까?우리 회사Liferay는 과거에 디자인 시스템에서 고정 구성 요소를 따르는 방법에 따라 개발자가 예상을 훨씬 초과할 수 없도록 했다. 300여 명의 엔지니어와 여러 개의 제품 팀을 보유한 회사 환경에서 이것은 잘못된 결정으로 인해 그룹의 채용률이 비교적 낮았다. 원인은 다음과 같다.

구성 요소와 설계 시스템

이 과잉 연결

유연성 저하

설계자가 실현 범위를 넘어선 구성 요소를 만들었다

따라서 당사의 구성 요소는 대형 API를 보유하고 있어 사용률이 낮고 구성의 복잡도가 높으며 유지 보수 비용이 증가하여 곧 감가상각 단계에 들어갑니다.
우리는 이것이 나쁜 결정이라는 것을 알고 이듬해 우리는 신속하게 다른 방법으로 방향을 바꿨다.우리는 구성 요소 라이브러리에서 유연성과 전용 구성 요소 사이의 균형을 실현하는 방법을 채택했다.
이 문제를 처리하는 것이 더 쉬운 것 같지만, 우리는 어떻게 이 생각을 실현합니까?Dell은 여러 계층의 API 라이브러리라고 하는 어셈블리를 블렌드하는 방법을 사용합니다.

다중 계층 API 라이브러리

다중 계층 구성요소는 다음과 같은 두 가지 방법으로 구성요소를 제공합니다.

로우 레벨 - 고급 구성 요소를 사용자 정의하고 만들 수 있는 유연성을 제공하는 기본 빌드 블록입니다.

고급 - 고도의 특정한 구성 요소는 종종 특정한 용례만 덮어쓰고 그것들의 유연성을 제한한다.

이런 원칙들은 매우 기본적이지만, '너는 약간의 규칙을 따라야 한다.' 라고 불려야 한다.

저수준

하단 구성 요소는 하단 구성 요소를 구축하는 작은 블록과 같은 조합을 따른다.

<ClayDropDown />
<ClayDropDown.Action />
<ClayDropDown.Item />
<ClayDropDown.ItemList />
<ClayDropDown.Search />

높은 수준

고급 구성 요소도 조합을 따를 수 있지만, 더욱 구체적인 구성 요소일 수도 있고, 많은 단체에서 공통점을 가지고 있다.

<ClayButtonWithIcon />
<ClayCardWithHorizontal />
<ClayCardWithNavigation />
<ClayDropDownWithItems />

고급 어셈블리는 유지 보수는 줄어들지만 사용 가능한 API의 표면은 늘어날 수 있는 하위 레벨로 구성됩니다.
이렇게 하면 더 많은 사람들이 이런 방법을 사용하고 다양한 품격의 팀을 참여시킬 수 있는 혼합 방법을 생각해 낼 수 있다는 장점이 있다.
당신은 우리composition approach in our documentation in our component library에 대한 더 많은 정보를 읽을 수 있습니다.
이런 방법의 결과는 우리의 부품이 서로 다른 팀과 서로 다른 환경에서의 제품에서 고도로 채용되어 팀이 제품을 더욱 빨리 납품하고 그들을 더욱 즐겁게 하도록 돕는 것이다.
이것은 사용자 차원의 문제를 해결한 것 같지만, 우리는 저급과 고급 구성 요소를 어떻게 구분하고 구축하며 구축하는지에 관한 몇 차례의 토론에 참여했다.이 방면에 대한 나의 생각들은 이론이나 개념성을 따르려는 시도와 시간의 추이에 따라 조정하려는 시도와는 다르다.

추이 이론

이것을 장미효과 이론과 혼동하지 마라.
꼬리 이론은 양쪽 또는 꼬리 부분의 밧줄 규범으로 한쪽 끝에 두 가지 유형의 조립품, 저급과 고급을 배치할 수 있다.그들 사이의 거리는 커다란 고통이나 큰 성공을 초래할 수 있다. 이것이 전부 혹은 전부다!

극단적인 상황은 매우 고통스러울 수도 있고 직접적일 수도 있다. 이것은 특정한 용례의 높은 부가 수준이 정의를 정확하게 따르는 단체에게 즐거움을 주고 정의를 지키지 않는 단체에게 많은 고통을 줄 수 있음을 의미한다.

고통에 처한 사람들에게 고통은 더욱 커질 것이다. 왜냐하면 낮은 층이 다른 한쪽에 있기 때문에 낮은 층에서 높은 층에 가까운 건물까지는 고통스러울 수 있기 때문이다.

극히 높은 등급의 사례는 매우 적게 채택될 수 있다. 왜냐하면 그들의 사례는 특정한 것이기 때문에 지정된 범위 밖에서 어떠한 변경도 허용하지 않는다.

낮은 수준은 수명이 비교적 길다. 왜냐하면 그들은 더욱 유연하기 때문이다. 그러나 자연히 더 많은 일을 필요로 한다.

더 많은 끼인 부품은 시간의 추이에 따라 더 큰 변화가 발생하고, 그들의 생명 주기는 왕왕 더욱 짧다.

이 그림은 가설적인 것으로, 여기에는 실제 데이터를 사용하지 않았지만, 내가 장기적으로 구성 요소 라이브러리를 사용한 경험을 바탕으로 한다.
몇 가지 특별한 것들: 단기와 장기적으로 우리는 아주 좋은 저급 업무를 할 수 있고 변화가 거의 없을 것이다. 이것은 우리에게 이상적인 장면이다. 그러나 중간에 우리는 노력과 개발 경험을 잃을 수 있다. 이것은 사람들이 라이브러리 구성 요소를 사용하고 힘들이지 않고 구축하는 관건이다.
시간의 추이에 따라 매우 구체적인 구성 요소는 짧은 시간 안에 많은 변화가 발생할 수 있다. 어느 때 우리는 구성 요소의 팽창 원인을 낮출 수 밖에 없다. 이것은 어떤 구성 요소에서 발생할 수 있지만 사람들이 그것을 사용하기 전에 우리는 유지보수 문제와 끊임없이 갱신하는 투쟁에 직면하게 될 것이다.우리는 이러한 구성 요소의 사용 수명을 연장하고 유지 보수를 줄일 수 있으며, 이렇게 하면 구성 요소 이외의 개선이나 구축을 걱정할 수 있다.
내가 부품을 밧줄의 중간에 점점 가까워지게 밀면 양쪽 사이의 거리가 줄어든다는 것은 우리가 양쪽의 통증을 줄였지만 가까워질수록 뚜렷한 차이가 없고 혼란을 초래할 수 있다는 것을 상상해 보자.매번 우리가 높은 수준의 사람들에게 유연성을 주고 그들을 밧줄 사이로 밀어내면 체험이 더욱 좋아지고 통증도 줄어든다.

우리는 쌍방에 가입하고 싶지 않지만 끝부분은 극단적이고 극단은 대가가 있다. 우리는 거리를 유지하고 싶을 뿐이다. 우리는 고위층 부품에 유연성을 제공하고 저층 부품의 유연성을 낮춰야 한다.
이 점을 감안하면 우리는 다음과 같이 할 수 있다.

고급 구성 요소의 수명을 연장합니다.

시간의 흐름에 따라 변화가 점점 적어진다

따라서 우리는 더 많은 용례를 지원한다

사람들이 더 즐거워

비록 가장 큰 장점은 높은 차원에 있지만 낮은 차원은 영향을 받을 것이다. 왜냐하면 우리가 그의 자연 유연성을 박탈하면 시간의 추이에 따라 변화량을 약간 증가시키고 그것에 대한 유지도 증가하지만 이것은 필요한 것이다. 왜냐하면 우리는 반드시 균형을 만들어야 하기 때문에 둘 사이의 차이가 뚜렷하지 않다.
나는 이 이론을 견지하는 것이 비교적 쉽다고 믿는다.이해하게 되면 어셈블리에 더 큰 유연성이 필요한 시기나 API를 유지 관리해야 하는 시기를 자연스럽게 결정할 수 있습니다.
Github을 통해 액세스할 수 있는 Liferay 구성 요소 라이브러리는 오픈 소스입니다.

Github:http://github.com/liferay/clay

장소: http://clayui.com

설계 시스템: https://liferay.design/lexicon/

나는 이 방면에서 이미 2년 반을 일했으니, 나는 너희들의 생각과 경험을 듣고 매우 기쁘다.
우리의 Github 저장소는 매우 재미있는 생각과 강연으로 가득 차 있다.우리의 문제와 관계를 탐색하다🙂.
인사해!👋 !