FE 개발 환경 복잡, 거대해짐 → 디자인 패터 사용에 대한 니즈가 생겨남
디자인 패턴
소프트웨어에서의 디자인 패턴이란
소프트웨어의 개발 방법, 정해진 설계 패턴
개발할 때 자주 발생하는 여러 문제점 고려, 특징 발견 → 설계의 노하우를 축적하여 이후에 이러한 노하우를 가져다가 재사용하기 좋은 형태로 특정 규약을 만들어서 정리한 것
구조적인 문제를 해결하는 방식
- 효율적인 코드를 만들기 위한 방법론
- 어떤 디자인 패턴을 꼭 적용해야 효율적인 코드를 만들 수 있는 것은 아님. 프로젝트(소프트웨어)의 규모, 형태, 특징 등을 고려해서 상황에 맞게 적용시키는 것이 중요
- 한 가지 패턴만 적용시키지 않고 유연하게 여러 패턴을 적용시켜서 효율적인 코드를 만드는 것이 좋음
- 코드로 구현된 구현체가 아닌 문제 해결을 위한 패턴 → 정해진 디자인 패턴을 적용할 때 자신의 개발 환경에 맞게 구현(그대로 or 변형)
- 최고의 개발자들이 만들어낸 증명된 솔루션
- 패턴대로 코드가 전개, 수정에 열려있는 구조 → 유지보수에 들어가는 비용 감소
- 언어에 제약x, 대부분의 디자인 패턴은 객체 지향적으로 문제를 해결하려고 함 → 객체 지향 언어를 사용하고 있을 경우에 대부분의 디자인 패턴을 쉽게 구현할 수 있음
아토믹 디자인 패턴(컴포넌트 중심 설계 패턴)
컴포넌트 기반 프로그래밍을 가능하게 해주는 여러 프레임워크를 사용하여 개발할 때 주로 사용되는 디자인 패턴.
UI를 원자, 분자, 유기체, 템플릿, 페이지의 계층 구조로 컴포넌트를 작성하는 패턴
원자
디자인과 기능의 최소 단위
대표적인 원자 컴포넌트: Label, Text, Container, Button, Icon
분자
여러 원자 컴포넌트를 합친 컴포넌트
Input forms, Navigation, Card 등
FE 개발자들이 컴포넌트를 만들 때 가장 많이 만드는 단위라고 함
유기체
분자를 묶어 관리
여러 카드를 합친 그리드, 입력폼과 내브 버튼을 감싼 내브바
유기체에 컴포넌트 단위는 프로젝트마다 다를 수 있음, 더 상위 컴포넌트인 템플릿이나 페이지로 관리할 수 있음
인터페이스의 ㄱ개별적인 영역을 형성
템플릿
여러 유기체가 모여있음
여러 카드 그리드를 묶어 하나의 템플릿 컴포넌트로 관리할 수 있음
이 템플릿을 페이지에서 직접 여러 그리드를 호출해서 관리할 수도 있음
페이지의 실제 컴포넌트가 없을 경우(실제 컨텐츠들이 배치되지 않을 때) 페이지에 대한 골격 구조
페이지
실제 컨텐츠들을 배치한 UI, 템플릿의 구체화된 인스턴스
뷰와 비지니스 로직을 분리 → 프로젝트가 확장될 때 코드에서 문제를 디버깅하기 더 쉬움
atoms, molecules로 공통된 레이아웃 컴포넌트를 만들기 좋음,
organisms, template 레벨은 프로젝트의 한정된 레이아웃을 뽑는데 좋음
organisms부터는 비지니스 로직을 보관하는 container와 1:1로 매칭시켜서 로직을 녹여내는 방법도 좋다
장점
어플리케이션과 분리하여 스토리북과 같은 툴로 컴포넌트를 테스트할 수 있음
일련의 패턴이 확립되면 → 설계 변경시나 에러 수정시에 더 빠르고 유연성있는 프로세스를 가질 수 있음
컴포넌트 재사용 → 디자인을 일관성 있게 통일
특정 컴포넌트에 css가 강하게 결합시켜 css를 쉽게 관리할 수 있음(해당 컴포넌트에서 사용되는 css만 렌더링)
단점
컴포넌트 간 의존성과 복잡도가 생각보다 까다로울 수 있음
어느 정도의 변화 또는 대형 변화에는 최적화된 패턴이지만 여러 변화가 누적되면서 변화에 의존하고 있은 컴포넌트들이 많다면 굉장히 수정 절차가 복잡해져 답이 없어짐, 의존성이 상하로 발생함 → 하위 컴포넌트에서 예상치 못한 에러가 발생 시 이 컴포넌트와 연결된 모든 상위 컴포넌트가 엉망이 됨
원자 단위를 보수적으로 관리할 필요가 있고, 이벤트 핸들링에 대해서느 수동적으로 관리할 필요가 있음
입력 필드와 같이 데이터를 처리하는 값에 대해서는 원자 단위보다는 한 단계 위인 분자 수준의 컴포넌트에서 관리하는 게 방어적 프로그래밍이 될 수 있음
컴포넌트 개념에 대한 높은 이해 필요 → 비개발자가 이해하기 힘듦
특히 각 컴포넌트를 어떻게 분류할지가 모호할 때가 많음 → 많은 논의 필요
모호한 이유
비슷하게 생긴 버튼 → 클릭시 항상 동일한 기능을 하는 버튼, state값에 따라 기능이 달라지는 버튼 like 로그인 상태인 경우 로그아웃 기능, 로그아웅ㅅ 상태인 경우 로그인 기능
화면 구성으로 ㄹㄹ봤을 때 ㅇ더이상 분류될 수 없는 atom 컴포넌트이지만 click hanling 함수가 너무 거대해서 molecule로 분류.. → 비슷하게 생겨도 다른 계층에 속하게 됨
만약 atom 계층에 넣고 부모 컴포넌트엥서 prop으로 전달할 수도 있겠지만 그렇게 되면 부모 컴포넌트가 너무 복잡해짐 → 따로 분리하여 컴포넌트가 스스로 데이터를 fetch하게 만듦
아토믹 디자인을 제대로 적용하기 위해서는 기획/디자인 단계에서부터 컴포넌트 단위의 체계화된 설계가 이뤄져야 함 → 리액트 컴포넌트의 state, prop 개념은 비개발자가 이해하기 힘듦 → 의사소통 비용 증가
새로운 개발자 합류 → 모호한 체계를 학습시켜야 함, 학습 비용의 증가, 문서와 여러 예시 필요
기존에 구현된 하위 컴포넌트들을 학습해야 새로운 상위 레벨의 컴포넌트를 구현할 수 있음
기획/디자인 변경 시 기획자와 디자이너가 컴포넌트, state/prop 이해도가 낮거나 없는 경우 → 컴포넌트를 합치거나 분리하거나 아예 컴포넌트 내부 구조를 변경해야 하는 등의 상황이 발생, 폰트 사이즈나 두께 등의 css 속성 값 등의 사소한 변경점들이 컴포넌트 체계에 치명적인 영향을 줄 수도 있음
결론
여러 장단점을 고려해서 프로젝트에 아토믹 디자인 시스템을 적용시킬지를 깊이 고민해보고 결정하자