BEM和UI切图命名
设计师学编程遇到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规范，毕竟还有其他的规范。
