設計師學編程遇到BEM
許多人第一次看到BEM都會覺得這東西好繁雜好長好難用啊，與之不同的是我第一次接觸BEM的時候覺得很熟悉，因為所學專業是設計專業，所以自然而然對于UI是有所接觸了解的，所以接觸BEM的時候覺得和UI切圖命名規范有異曲同工之妙。
所以便萌發了一個是否可以用UI切圖命名規范來理解BEM的想法。
BEM是什么
首先我們的理解BEM是什么，BEM是由Yandex團隊提出的一種CSS Class 命名方法，下文引用來自：https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
BEM – meaningblock,element,modifier– is a front-end naming methodology thought up by the guys atYandex. It is a smart way of naming your CSS classes to give them more transparency and meaning to other developers. They are far more strict and informative, which makes the BEM naming convention ideal for teams of developers on larger projects that might last a while.
大意就是BEM是Yandex團隊提出的這種命名方法可以讓你的CSS類名對于其他開發者更加友好，也更加有利于維護的意思。
說通俗一點就是BEM就是一個類名規則，高級一點呢可以說BEM是一種前端編程思想
BEM的命名模式如下
.block{}
.block__element{}
.block--modifier{}
.block{} 代表了更高級別的抽象或組件
.block__element{} blcok后代， 用于形成一個完成的.block整體，用（__）連接
.block--modifier{} block不同狀態或不同版本 用(--)連接
通俗一點來理解的就是
- B Block 網頁某一塊展示功能區域 div nav
舉個栗子：header-tabs 頭部的 - E element Block里面的某個元素 nav__item
舉個栗子： E .header-tabs__item - M Modifier 某個元素的狀態 .nav--hide nav__item--active
舉個栗子：header-tabs__item--avtive
UI切圖命名又是怎么樣的
UI切圖的命名并不像BEM有團隊提出。也就是說命名并不是統一的規范，但是都差不多。
一般都是類別+功能+狀態.png這個樣子的，比如：icon_home_default代表的就是圖標主頁默認的意思。當然很多公司的大項目都是會分成很多模塊來做，所以命名格式又分為兩種，一種是通用類型的切圖，還有一種就是各個模塊特有的切圖。
通用切片命名格式：
組件類別功能狀態@2x.png
舉例：tabbar_icon_home_default@2x.png
（對應中文：標簽欄圖標主頁默認@2x.png）
模塊特有切圖命名規則：
模塊類別功能狀態@2x.png
舉例：mail_icon_search_pressed@2x.png
（對應的中文為：郵件圖標搜索 默認@2x.png）
（@2x.png是在retina屏幕使用需要添加的）
對比
BEM:
.block{} 代表了更高級別的抽象或組件
.block__element{} blcok后代， 用于形成一個完成的.block整體，用（__）連接
.block--modifier{} block不同狀態或不同版本 用(--)連接UI切圖命名：
模塊類別功能狀態@2x.png
舉例：mail_icon_search_pressed@2x.png
（對應的中文為：郵件圖標搜索 默認@2x.png）
對比發現其實是有所共同點，都是在一個層級區塊下接著另一個層級隨后各處狀態。但是不同的是UI切圖命名相比BEM要簡單很多，BEM更加規范，并且有其他的注意點，比如：一個修飾符不能再它所屬的上下文環境之外被使用、不推薦在元素內部嵌套元素之類的。
所以如果需要詳細了解BEM可以訪問大漠老師的網站：http://www.w3cplus.com/css/mindbemding-getting-your-head-round-bem-syntax.html
里面給了詳細的講解。
規范的作用
-
節省時間，方便團隊協作
一個app的開發需要經歷產品經理->交互設計師->視覺設計師->前端->后端，產品經理需要給出合格的PRD文檔給交互設計師，交互設計師要給出合格的交互原型給視覺設計師，視覺設計師則要做好視覺稿切好圖命好名給前端，前端需要給后端合格的頁面框架樣式。
這是我最開始作圖時的命名，很明顯，只有我自己懂每個頁面是什么意思，給前端或許需要交流半天才可以懂。
包括我最開始所做的交互文檔，也是只有自己才看的懂。
如果各自所做的東西都按著規范來，那么自然不需要通過交流解釋來浪費時間，當然上述流程是以前的流程，現今流程則是各個職業都需要相互交流，并不是簡單的一環扣一環。交互設計師也已經需要和前端交流。 - 更好的修改
許多項目都需要進行迭代，進行修復。
UI命名好的話后期修改文件快捷，前端使用BEM進行編寫代碼也會有利于后期的修改，代碼的復用性也極高。大部分項目適用相同的組件。 代碼的復用顯著地降低了開發成本和時間。 - 提生自身的專業性
使用公認的規范操作會讓人覺得你更加專業。
當然并不是所有事情都需要遵守規范，以一些初創型公司來說，產品經理并不需要些PRD文檔，因為耗費時間，而前端也不一定需要使用BEM規范，畢竟還有其他的規范。
