CDD ( Component-Driven Development )

현채은·2023년 4월 18일

💡CDD (Component-Driven Development )

➡️ 레고처럼 조립해 나갈 수 있는 부품단위로 UI컴포넌트를 만들어 나가는 개발 방법

구조화 된 CSS가 왜 필요할까 ?
- 점점 커지는 프로젝트의 규모에 따른 팀원 수 증가
- 모바일이나 태블릿을 비롯한 다양한 템플릿의 등장
- CSS작업을 효율적으로 하기 위해서는 구조화 된 CSS가 필요하다 !
이러한 문제점을 해결하기 위해 "CSS 전처리기(CSS Preprocessor)" 등장
- CSS 전처리기란 ?
  ➡️ CSS가 구조적으로 작성될 수 있게 도움을 주는 도구
- CSS 문서 작성시 많은 반복적인 작업 요구 + Color값을 찾는 일, tag를 닫는 일 등 번거로운 작업이 많음
- 클래스, 상속과 같은 사항으로 점점 CSS 문서는 양이 많아지고 이후 유지관리에 많은 영향을 끼침
- 이러한 CSS 문제점들을 프로그래밍 개념( 변수, 함수, 상속 등 ) 을 활용하여 해결해 나갈 수 있음
  but ) CSS 전처리기 자체만으로는 웹서버가 인지하지 못함
  ➡️ 각 CSS 전처리기에 맞는 Compiler를 사용해야함
  ➡️ Compiler를 사용하면 우리가 사용하는 CSS문서로 변환

'CSS를 만들어주는 언어' 로서 자바스크립트처럼 특정 속성의 값 등을 변수로 선언하여 필요한 곳에 적용
반복되는 코드를 한 번의 선언으로 여러 곳에서 재사용 가능
➡️ SASS는 SCSS 코드를 읽어서 전처리 후 컴파일해서 전역 CSS번들 파일을 만들어주는 전처리 역할을 함
➡️ 하지만 얼마 지나지 않아 CSS 구조화를 해결해주는 것의 장점보다 다른 문제들을 더 많이 만들어낸다는 것이 밝혀짐
결국 전처리기가 내부에서 어떤 작업을 하는지 알지 못한 채, 스타일이 겹치는 문제를 해결하기 위해 단순히 계층구조를 만들어 내는 것에 의지 ➡️ 컴파일 된 CSS의 용량은 어마어마하게 커지게 됨

이러한 CSS 전처리기의 문제를 보완하기 위해 BEM, OOCSS, SMACSS 같은 CSS 방법론이 대두되었음
각각의 장단점이 있으나 결국 세 방법론 모두 같은 지향점을 가지고 있음
방법론의 공통 지향점
- 코드의 재사용
- 코드의 간결화 (유지 보수 용이)
- 코드의 확장성
- 코드의 예측성 (클래스 명으로 의미 예측)
이러한 방법론들 ➡️ 같이 일하는 팀 동료들의 팀워크와도 연결
팀원이 함께 작업하는 상황에서 CSS 작성에 있어서 방법들을 규칙으로 정해두는 것? 매우 중요하다.

Block, Element, Modifier 로 구분하여 클래스명을 작성하는 방법
Block : 전체를 감싸고 있는 블럭요소
Element: 블럭이 포함하고 있는 한조각
Modifier : 블럭 또는 요소의 속성 ( 블록이나 엘리먼트의 외관이나 상태를 변화가능하게 하는 부분 )
➡️ 이러한 방법론들에서도 문제점이 발생한다.....
클래스명 선택자가 장황, 마크업 불필요 이상 과대, 재사용시, UI 컴포넌트를 명시적으로 확장