Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BEM을 깨우치다.

6,932 views

Published on

프론트엔드 개발 방법론 중 하나인 BEM을 소개합니다.

Published in: Engineering
  • Login to see the comments

BEM을 깨우치다.

  1. 1. BEM을 깨우치다.
  2. 2. BEM이란? • 러시아의 큰 기업인 Yandex에서 탄생 • 코딩 스타일이 아님, 개발 및 설계 방법론 • 객체를 코드로 표현하는 방법과 일련의 패턴 • 프로그래밍 방법에 관한 보편적 지식 블럭(Block), 요소(Element), 변환자(Modifier)
  3. 3. BEM의 목표 빠른 개발 속도 단계적이 아닌 병렬적으로 개발을 진행하여 웹 사이트의 첫 버전을 신속하게 공개
  4. 4. BEM의 목표 빠른 개발 속도 효율적인 유지보수 단계적이 아닌 병렬적으로 개발을 진행하여 웹 사이트의 첫 버전을 신속하게 공개 오랜기간 동안 효율적으로 유지보수 할 수 있는 구조와 커뮤니케이션 방법 확립
  5. 5. BEM의 목표 빠른 개발 속도 효율적인 유지보수 팀의 확장성 단계적이 아닌 병렬적으로 개발을 진행하여 웹 사이트의 첫 버전을 신속하게 공개 오랜기간 동안 효율적으로 유지보수 할 수 있는 구조와 커뮤니케이션 방법 확립 급격한 학습 곡선 없이 새로운 맴버를 할당할 수 있는 환경 조성
  6. 6. BEM의 목표 빠른 개발 속도 효율적인 유지보수 팀의 확장성 코드의 재사용 단계적이 아닌 병렬적으로 개발을 진행하여 웹 사이트의 첫 버전을 신속하게 공개 오랜기간 동안 효율적으로 유지보수 할 수 있는 구조와 커뮤니케이션 방법 확립 급격한 학습 곡선 없이 새로운 맴버를 할당할 수 있는 환경 조성 UI의 일관성을 유지하고 재사용성을 높이기 위해 문맥적인 의존 없는 모듈 개발
  7. 7. 페이지 1 페이지 2 페이지 3 페이지 1 페이지 2 페이지 3 디자이너 마크업 단계적 개발 페이지 1 페이지 2프론트엔드
  8. 8. 페이지 1 페이지 2 페이지 3 페이지 1 페이지 2 페이지 3 디자이너 마크업 단계적 개발 통상적인 개발 프로세스는 불규칙하게 변하는 요구사항의 변동성을 크게 고려하지 않고 있으며 디자이너와 마크업 개발자 그리고 프론트엔드 개발자가 각자의 영역에서 작업하고 서로 간섭하는 일이 없는 환경을 근간으로 하고 있다. 페이지 1 페이지 2프론트엔드
  9. 9. 페이지 1 페이지 2 페이지 3 페이지 1 페이지 2 페이지 3 디자이너 마크업 단계적 개발 통상적인 개발 프로세스는 불규칙하게 변하는 요구사항의 변동성을 크게 고려하지 않고 있으며 디자이너와 마크업 개발자 그리고 프론트엔드 개발자가 각자의 영역에서 작업하며 서로 간섭하는 일이 없는 환경을 근간으로 하고 있다. 추가되는 요구 사항이 시스템에 큰 영향을 주지 않는다면 무리 없지만 대개는 그렇지 않다. 웹은 항상 변경에 열려 있고 디자인은 변화하며 완전히 새로운 페이지나 요소도 추가된다. 페이지 1 페이지 2프론트엔드
  10. 10. 영역디자이너 개발자 병렬적 개발 영역 영역 영역 영역 영역 영역 태그 태그 태그 태그 태그 태그 태그 영역 태그 프론트엔드 모듈 모듈 모듈 모듈 모듈 모듈 모듈
  11. 11. 영역디자이너 개발자 병렬적 개발 영역 영역 영역 영역 영역 영역 태그 태그 태그 태그 태그 태그 태그 영역 태그 문제의 범위를 작게 나눠 개발을 최대한 병렬적으로 진행한다. 문제의 범위가 작으면 변경에 기민하게 대처 할 수 있다. 프론트엔드 모듈 모듈 모듈 모듈 모듈 모듈 모듈
  12. 12. 영역디자이너 개발자 병렬적 개발 영역 영역 영역 영역 영역 영역 태그 태그 태그 태그 태그 태그 태그 영역 태그 문제의 범위를 작게 나눠 개발을 최대한 병렬적으로 진행한다. 문제의 범위가 작으면 변경에 기민하게 대처 할 수 있다. 이때 중요한 것은 영역의 크기는 공통적이어야 하며 사용하는 언어도 통일되어야 한다는 점이다. 개발 분야 간 영역의 크기와 언어가 합을 이루지 못하면 유지보수가 어려워진다. 프론트엔드 모듈 모듈 모듈 모듈 모듈 모듈 모듈
  13. 13. Unified Data Domain 서로 각자 간섭없이 개발하는게 아니라 블럭(Block)의 이름을 함께 짓고, 이해관계자가 공통적으로 용어를 사용한다. 이를 Unified Data Domain이라고 한다.
  14. 14. Unified Data Domain 서로 각자 간섭없이 개발하는게 아니라 블럭(Block)의 이름을 함께 짓고, 이해관계자가 공통적으로 용어를 사용한다. 이를 Unified Data Domain이라고 한다. 각 영역에 이름을 붙이고 함께 사용하면 커뮤니케이션 비용을 낮출 수 있다. 변경이 필요한 영역을 정확하게 알려줄 수 있고 각 영역을 조합해 새로운 영역을 만들어 낼 때도 몇 마디 만으로 의사를 전달할 수 있다.
  15. 15. 블럭(Block) 애플리케이션의 구성 요소로써 독립된 존재 블럭은 문맥 의존적이지 않은 독립된 객체 또는 높은 수준으로 추상화한 컴포넌트다. 하위에 요소만 포함할 수도 있고, 또 다른 블럭을 포함할 수도 있다.
  16. 16. 요소(Element) 영역을 구성하는 작은 단위 또는 자식 요소는 블럭을 구성하는 작은 단위로써 특정 기능을 담당한다. 블럭과 달리 문맥 의존적이며 요소가 속한 블럭 내에서만 의미를 가진다.
  17. 17. 변환자(Modifier) 블럭이나 요소의 스타일이나 동작을 표현 숨겨놓은 요소를 출력하거나 특정 버튼에 커서를 올렸을 때 배경색을 변경하는 등 블럭이나 요소의 상태를 표현한다. 기존과 비슷하지만 스타일이나 동작이 조금 다른 블럭이나 요소를 만들고 싶은 경우에 사용한다.
  18. 18. 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
  19. 19. 가상 시나리오, Promise - mozilla | MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
  20. 20. 블럭 나누고 이름 짓기 이 블럭의 이름은 뭐가 좋을까요? 빠르게 접근할 수 있는 메뉴니까 QuickMenu가 어떨까요? 디자이너와 함께 블럭(또는 요소, 변환자)의 
 이름을 정한다. 한 페이지의 디자인이 모두 완료 될 때까지 기다리는게 아니라 블럭마다 디자인 결과물을 전달받아 모듈을 개발한다.
  21. 21. header logo auth tabzilla nav search auth-means auth-picker nav-submenu footer
  22. 22. metabreadcrumbs settingcontent contributor toc quick-menu wiki message-box message-box
  23. 23. 요소와 변환자 찾아내기 블럭을 나누고 이름을 지었으면 블럭을 구성하는 요소를 판별한다. 또한 블럭과 요소에 필요한 변환자도 찾아낸다. 이 블럭을 구성하는 요소는 이것...!
  24. 24. 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
  25. 25. 마크업, 스타일링 영역별로 HTML 파일과 SASS 파일을 나누고... 블럭의 이름을 결정하고, 블럭 디자인을 전달 받으면 마크업 및 스타일링 작업에 들어간다. 블럭 이름으로 HTML 파일과 SASS 파일을 생성하고 문맥 의존적이지 않도록 모듈을 작성한다.
  26. 26. breadcrumbs.html
  27. 27. breadcrumbs.html _breadcrumbs.scss
  28. 28. breadcrumbs.html _breadcrumbs.scss 블럭은 하나의 객체로써 독립된 존재로 사고하고 행동한다. 문맥을 의존하지 않고 동작하도록 유념하여 스타일을 작성한다.
  29. 29. 파일명 만 보더라도 어느 블럭의 마크업인지 또는 스타일링인지 즉각 알 수 있다. 디자이너가 특정 블럭의 디자인을 변경하면 빠르게 접근하여 반영할 수 있다. 또한몇몇블럭을조합해새로운블럭을만들어도 작은 단위로 나누었기 때문에 빠르게 개발할 수 있다. Sass 3 부터 MindBEMding 명명법으로 서술하기에 적합한 @at-root, # {} 보간이 추가 됐기 때문에 이 둘은 이질감 없이 잘 어울린다.
  30. 30. 자바스크립트 자바스크립트에서 블럭은 하나의 뷰 및 뷰 컴 포넌트 또는 템플릿 단위가 된다. 블럭별로 잘 컴포넌트화 하여 UI 개발에서 유용하게 사용 한다. 블럭별로 분리한 마크업을 이용해 컴포넌트를 잘 만들어 보자.
  31. 31. breadcrumbsItem.js breadcrumbs.js
  32. 32. 이처럼 블럭은 디자인, 마크업, 프론트엔드 개발 모두 공통으로 사용되는 개념이다. React는 뷰를 컴포넌트 단위로 작성하기 때문에 BEM 방법론과 잘 어울린다. breadcrumbsItem.js breadcrumbs.js
  33. 33. 목표달성 및 기대효과
  34. 34. 문제의 크기를 작게 나누면 병렬적으로 개발가능하고 변경에 기민하게 대응할 수 있어 빠르게 개발할 수 있다. 목표달성 및 기대효과
  35. 35. 문제의 크기를 작게 나누면 병렬적으로 개발가능하고 변경에 기민하게 대응할 수 있어 빠르게 개발할 수 있다. 이해관계자가 공통으로 이해하는 용어로 소통하고, 파일명 만으로도 변경이 필요한 블럭을 추적할 수 있어 유지보수에 용이하다. 목표달성 및 기대효과
  36. 36. 목표달성 및 기대효과 문제의 크기를 작게 나누면 병렬적으로 개발가능하고 변경에 기민하게 대응할 수 있어 빠르게 개발할 수 있다. 이해관계자가 공통으로 이해하는 용어로 소통하고, 파일명 만으로도 변경이 필요한 블럭을 추적할 수 있어 유지보수에 용이하다. 단순하고 명확한 규칙과 명명법으로 새로운 팀원이 투입되도 큰 이해 비용 없이 개발에 착수 할 수 있다.
  37. 37. 문제의 크기를 작게 나누면 병렬적으로 개발가능하고 변경에 기민하게 대응할 수 있어 빠르게 개발할 수 있다. 이해관계자가 공통으로 이해하는 용어로 소통하고, 파일명 만으로도 변경이 필요한 블럭을 추적할 수 있어 유지보수에 용이하다. 단순하고 명확한 규칙과 명명법으로 새로운 팀원이 투입되도 큰 이해 비용 없이 개발에 착수 할 수 있다. 문맥을 의존하지 않는 단일 객체로써 블럭을 모듈(컴포넌트)화 하여 재사용성을 극대화할 수 있다. 목표달성 및 기대효과
  38. 38. 개인적으로 느낀 점 기존 문제 BEM
  39. 39. 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다. 개인적으로 느낀 점 기존 문제 BEM
  40. 40. 개인적으로 느낀 점 작은 영역별로 디자인하고 함께 이름을 정하고 전달한다. 영역의 디자인은 페이지에 비해 금방 공유 받을 수 있기 때문에 병목을 줄일 수 있다. 기존 문제 BEM 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다.
  41. 41. 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다. 전체 사이트가 디자인 되기 전까지 어느 요소가 공통 요소인지 파악하기 힘들다. 개인적으로 느낀 점 기존 문제 BEM 작은 영역별로 디자인하고 함께 이름을 정하고 전달한다. 영역의 디자인은 페이지에 비해 금방 공유 받을 수 있기 때문에 병목을 줄일 수 있다.
  42. 42. 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다. 전체 사이트가 디자인 되기 전까지 어느 요소가 공통 요소인지 파악하기 힘들다. 개인적으로 느낀 점 작은 영역별로 디자인하고 함께 이름을 정하고 전달한다. 영역의 디자인은 페이지에 비해 금방 공유 받을 수 있기 때문에 병목을 줄일 수 있다. 어느 영역을 개발하든 문맥 의존적이지 않도록 개발하기 때문에 또 다른 페이 지에서 사용이 필요하면 언제든지 사용 할 수 있다. 기존 문제 BEM
  43. 43. 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다. 전체 사이트가 디자인 되기 전까지 어느 요소가 공통 요소인지 파악하기 힘들다. 페이지 단위 개발은 문제의 범위가 크기 때문에 페이지 전체적인 변경 사항이 생기기 마련이다. 개인적으로 느낀 점 기존 문제 BEM 작은 영역별로 디자인하고 함께 이름을 정하고 전달한다. 영역의 디자인은 페이지에 비해 금방 공유 받을 수 있기 때문에 병목을 줄일 수 있다. 어느 영역을 개발하든 문맥 의존적이지 않도록 개발하기 때문에 또 다른 페이 지에서 사용이 필요하면 언제든지 사용 할 수 있다.
  44. 44. 페이지 전체를 작업하고 전달하면 개발에 병목이 생긴다. 전체 사이트가 디자인 되기 전까지 어느 요소가 공통 요소인지 파악하기 힘들다. 페이지 단위 개발은 문제의 범위가 크기 때문에 페이지 전체적인 변경 사항이 생기기 마련이다. 개인적으로 느낀 점 작은 영역별로 디자인하고 함께 이름을 정하고 전달한다. 영역의 디자인은 페이지에 비해 금방 공유 받을 수 있기 때문에 병목을 줄일 수 있다. 어느 영역을 개발하든 문맥 의존적이지 않도록 개발하기 때문에 또 다른 페이 지에서 사용이 필요하면 언제든지 사용 할 수 있다. 영역 별로 나눈 문제의 범위는 크기가 작기 때문에 변경에 대처하기 쉽다. 기존 문제 BEM
  45. 45. 개인적으로 느낀 점 단점
  46. 46. 개인적으로 느낀 점 괴상한 명명법, BEM 방법론은 명명법을 강제하지 않으나 딱히 대안이 없다. 단점
  47. 47. 개인적으로 느낀 점 괴상한 명명법, BEM 방법론은 명명법을 강제하지 않으나 딱히 대안이 없다. 블럭이 다른 상위 블럭이나 요소의 상태에 영향받지 않도록 섬세하게 다루고 예의 주시 해야한다. 단점
  48. 48. 개인적으로 느낀 점 괴상한 명명법, BEM 방법론은 명명법을 강제하지 않으나 딱히 대안이 없다. 블럭이 다른 상위 블럭이나 요소의 상태에 영향받지 않도록 섬세하게 다루고 예의 주시 해야한다. 프로젝트 이해관계자 모두 가치를 공감하고 함께 행동해야한다. 단점
  49. 49. 개인적으로 느낀 점 괴상한 명명법, BEM 방법론은 명명법을 강제하지 않으나 딱히 대안이 없다. 블럭이 다른 상위 블럭이나 요소의 상태에 영향받지 않도록 섬세하게 다루고 예의 주시 해야한다. 프로젝트 이해관계자 모두 가치를 공감하고 함께 행동해야한다. 투자한 노력에 비해 재사용하게 될 블럭은 몇 안 될 것 같다. 단점
  50. 50. • 예제 저장소 : 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
  51. 51. Companies using BEM
  52. 52. Yandex https://www.yandex.com
  53. 53. JetBrains http://jetbrains.com
  54. 54. Sony Japan http://www.sony.jp
  55. 55. Nintendo Japan http://www.nintendo.co.jp/wiiu/index.html
  56. 56. SOUNDCLOUD https://soundcloud.com
  57. 57. http://www.lonelyplanet.com http://rizzo.lonelyplanet.com/styleguide/ui-components/cards
  58. 58. http://topcoat.io/topcoat
  59. 59. 감사합니다.

×