BEM을 깨우치다.

BEM이란?
• 러시아의 큰 기업인 Yandex에서 탄생
• 코딩 스타일이 아님, 개발 및 설계 방법론
• 객체를 코드로 표현하는 방법과 일련의 패턴
• 프로그래밍 방법에 관한 보편적 지식
블럭(Block), 요소(Element), 변환자(Modifier)

BEM의 목표
빠른 개발 속도
단계적이 아닌 병렬적으로 개발을 진행하여
웹 사이트의 첫 버전을 신속하게 공개

BEM의 목표
효율적인 유지보수
오랜기간 동안 효율적으로 유지보수 할 수 있는
구조와 커뮤니케이션 방법 확립

BEM의 목표
팀의 확장성
급격한 학습 곡선 없이 새로운 맴버를 할당할 수
있는 환경 조성

BEM의 목표
팀의 확장성
코드의 재사용
급격한 학습 곡선 없이 새로운 맴버를 할당할 수
있는 환경 조성
UI의 일관성을 유지하고 재사용성을 높이기 위해
문맥적인 의존 없는 모듈 개발

페이지 1 페이지 2 페이지 3
디자이너
마크업
단계적 개발
페이지 1 페이지 2프론트엔드

디자이너
마크업
단계적 개발
통상적인 개발 프로세스는 불규칙하게 변하는 요구사항의 변동성을 크게 고려하지 않고 있으며 디자이너와
마크업 개발자 그리고 프론트엔드 개발자가 각자의 영역에서 작업하고 서로 간섭하는 일이 없는 환경을
근간으로 하고 있다.

디자이너
마크업
단계적 개발
통상적인 개발 프로세스는 불규칙하게 변하는 요구사항의 변동성을 크게 고려하지 않고 있으며 디자이너와
마크업 개발자 그리고 프론트엔드 개발자가 각자의 영역에서 작업하며 서로 간섭하는 일이 없는 환경을
근간으로 하고 있다.
추가되는 요구 사항이 시스템에 큰 영향을 주지 않는다면 무리 없지만 대개는 그렇지 않다. 웹은 항상 변경에
열려 있고 디자인은 변화하며 완전히 새로운 페이지나 요소도 추가된다.

영역디자이너
개발자
병렬적 개발
영역 영역 영역 영역 영역 영역
태그 태그 태그 태그 태그 태그 태그
영역
태그
프론트엔드 모듈 모듈 모듈 모듈 모듈 모듈 모듈

영역디자이너
개발자
병렬적 개발
영역
태그
문제의 범위를 작게 나눠 개발을 최대한 병렬적으로 진행한다. 문제의 범위가 작으면 변경에 기민하게
대처 할 수 있다.

영역디자이너
개발자
병렬적 개발
영역
태그
문제의 범위를 작게 나눠 개발을 최대한 병렬적으로 진행한다. 문제의 범위가 작으면 변경에 기민하게
대처 할 수 있다.
이때 중요한 것은 영역의 크기는 공통적이어야 하며 사용하는 언어도 통일되어야 한다는 점이다. 개발 분야
간 영역의 크기와 언어가 합을 이루지 못하면 유지보수가 어려워진다.

Unified Data Domain
서로 각자 간섭없이 개발하는게 아니라 블럭(Block)의 이름을 함께 짓고, 이해관계자가 공통적으로 용어를
사용한다. 이를 Unified Data Domain이라고 한다.

Unified Data Domain
서로 각자 간섭없이 개발하는게 아니라 블럭(Block)의 이름을 함께 짓고, 이해관계자가 공통적으로 용어를
사용한다. 이를 Unified Data Domain이라고 한다.
각 영역에 이름을 붙이고 함께 사용하면 커뮤니케이션 비용을 낮출 수 있다. 변경이 필요한 영역을
정확하게 알려줄 수 있고 각 영역을 조합해 새로운 영역을 만들어 낼 때도 몇 마디 만으로 의사를 전달할 수
있다.

블럭(Block)
애플리케이션의 구성 요소로써 독립된 존재 블럭은 문맥 의존적이지 않은 독립된 객체 또는
높은 수준으로 추상화한 컴포넌트다.
하위에 요소만 포함할 수도 있고, 또 다른 블럭을
포함할 수도 있다.

요소(Element)
영역을 구성하는 작은 단위 또는 자식 요소는 블럭을 구성하는 작은 단위로써 특정 기능을
담당한다. 블럭과 달리 문맥 의존적이며 요소가 속한
블럭 내에서만 의미를 가진다.

변환자(Modifier)
블럭이나 요소의 스타일이나 동작을 표현 숨겨놓은 요소를 출력하거나 특정 버튼에 커서를
올렸을 때 배경색을 변경하는 등 블럭이나 요소의
상태를 표현한다.
기존과 비슷하지만 스타일이나 동작이 조금 다른
블럭이나 요소를 만들고 싶은 경우에 사용한다.

MindBEMding
BEM 방법론을 기반으로 한 명명법 BEM은 클래스 명명 규칙을 강제하지 않는다. 많은 사람이
오해하고 있는 호불호가 극명하게 갈리는 명명법은 BEM
방법론을 기반으로 한 MindBEMding 명명법이다. 
다른 것으로 modified BEM이 있다.
• .block{} : 영역
• .block__element{} : .block을 지원하는 자식 요소
• .block—modifier{} : .block의 상태를 나타내는 변환자
modified BEM : https://pages.18f.gov/frontend/css-coding-styleguide/naming
MindBEMding : http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax

가상 시나리오, Promise - mozilla | MDN
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

블럭 나누고 이름 짓기
이 블럭의 이름은
뭐가 좋을까요?
빠르게 접근할 수
있는 메뉴니까 QuickMenu가
어떨까요?
디자이너와 함께 블럭(또는 요소, 변환자)의  
이름을 정한다. 한 페이지의 디자인이 모두
완료 될 때까지 기다리는게 아니라 블럭마다
디자인 결과물을 전달받아 모듈을 개발한다.

header
logo
auth tabzilla
nav search
auth-means
auth-picker
nav-submenu
footer

metabreadcrumbs settingcontent
contributor
toc
quick-menu
wiki
message-box
message-box

요소와 변환자 찾아내기
블럭을 나누고 이름을 지었으면 블럭을
구성하는 요소를 판별한다. 또한 블럭과
요소에 필요한 변환자도 찾아낸다.
이 블럭을 구성하는 요소는
이것...!

nav-submenu—col-2
nav-submenu__close
nav-submenu__column nav-submenu__list nav-submenu__item
nav-submenu
message-box—warning
message-box—note
message-box—syntax

마크업, 스타일링
영역별로 HTML 파일과
SASS 파일을 나누고...
블럭의 이름을 결정하고, 블럭 디자인을 전달
받으면 마크업 및 스타일링 작업에 들어간다.
블럭 이름으로 HTML 파일과 SASS 파일을
생성하고 문맥 의존적이지 않도록 모듈을
작성한다.

breadcrumbs.html _breadcrumbs.scss

breadcrumbs.html _breadcrumbs.scss
블럭은 하나의 객체로써 독립된 존재로 사고하고 행동한다.
문맥을 의존하지 않고 동작하도록 유념하여 스타일을 작성한다.

파일명 만 보더라도 어느 블럭의 마크업인지
또는 스타일링인지 즉각 알 수 있다.
디자이너가 특정 블럭의 디자인을 변경하면
빠르게 접근하여 반영할 수 있다.
또한몇몇블럭을조합해새로운블럭을만들어도
작은 단위로 나누었기 때문에 빠르게 개발할
수 있다.
Sass 3 부터 MindBEMding 명명법으로
서술하기에 적합한 @at-root, # {} 보간이
추가 됐기 때문에 이 둘은 이질감 없이 잘
어울린다.

자바스크립트
자바스크립트에서 블럭은 하나의 뷰 및 뷰 컴
포넌트 또는 템플릿 단위가 된다. 블럭별로 잘
컴포넌트화 하여 UI 개발에서 유용하게 사용
한다.
블럭별로 분리한
마크업을 이용해
컴포넌트를 잘 만들어 보자.

breadcrumbsItem.js
breadcrumbs.js

이처럼 블럭은 디자인, 마크업, 프론트엔드 개발 모두 공통으로 사용되는 개념이다.
React는 뷰를 컴포넌트 단위로 작성하기 때문에 BEM 방법론과 잘 어울린다.
breadcrumbsItem.js
breadcrumbs.js

문제의 크기를 작게 나누면 병렬적으로 개발가능하고
변경에 기민하게 대응할 수 있어 빠르게 개발할 수 있다.
목표달성 및 기대효과

이해관계자가 공통으로 이해하는 용어로 소통하고,
파일명 만으로도 변경이 필요한 블럭을 추적할 수 있어 유지보수에 용이하다.

단순하고 명확한 규칙과 명명법으로 새로운 팀원이 투입되도
큰 이해 비용 없이 개발에 착수 할 수 있다.

단순하고 명확한 규칙과 명명법으로 새로운 팀원이 투입되도
큰 이해 비용 없이 개발에 착수 할 수 있다.
문맥을 의존하지 않는 단일 객체로써 블럭을 모듈(컴포넌트)화 하여
재사용성을 극대화할 수 있다.

개인적으로 느낀 점
기존 문제 BEM

페이지 전체를 작업하고 전달하면
개발에 병목이 생긴다.
기존 문제 BEM

작은 영역별로 디자인하고 함께 이름을
정하고 전달한다. 영역의 디자인은
페이지에 비해 금방 공유 받을 수 있기
때문에 병목을 줄일 수 있다.
기존 문제 BEM

전체 사이트가 디자인 되기 전까지
어느 요소가 공통 요소인지 파악하기
힘들다.
기존 문제 BEM

힘들다.
어느 영역을 개발하든 문맥 의존적이지
않도록 개발하기 때문에 또 다른 페이
지에서 사용이 필요하면 언제든지
사용 할 수 있다.
기존 문제 BEM

힘들다.
페이지 단위 개발은 문제의 범위가
크기 때문에 페이지 전체적인 변경
사항이 생기기 마련이다.
기존 문제 BEM

힘들다.
페이지 단위 개발은 문제의 범위가
크기 때문에 페이지 전체적인 변경
사항이 생기기 마련이다.
영역 별로 나눈 문제의 범위는 크기가
작기 때문에 변경에 대처하기 쉽다.
기존 문제 BEM

단점

괴상한 명명법, BEM 방법론은 명명법을 강제하지 않으나 딱히 대안이 없다.
단점

블럭이 다른 상위 블럭이나 요소의 상태에 영향받지 않도록 섬세하게 다루고 예의
주시 해야한다.
단점

프로젝트 이해관계자 모두 가치를 공감하고 함께 행동해야한다.
단점

프로젝트 이해관계자 모두 가치를 공감하고 함께 행동해야한다.
투자한 노력에 비해 재사용하게 될 블럭은 몇 안 될 것 같다.
단점

• 예제 저장소 : https://github.com/UYEONG/bem-style-mdn 
 
• 데모 : http://uyeong.github.io/bem-style-mdn/index.html 
 
• 분해도 : http://uyeong.github.io/bem-style-mdn/anatomy.html

JetBrains
http://jetbrains.com

Nintendo Japan
http://www.nintendo.co.jp/wiiu/index.html

SOUNDCLOUD
https://soundcloud.com

http://www.lonelyplanet.com
http://rizzo.lonelyplanet.com/styleguide/ui-components/cards

BEM을 깨우치다.

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a BEM을 깨우치다.

Similar a BEM을 깨우치다. (20)

Más de 우영 주

Más de 우영 주 (13)

Último

Último (8)

BEM을 깨우치다.