经过一期带团队的体验，我发现文件命名有点让人抓狂，实在忍不住更新一篇文章去说说这其中大家约定俗成的规则，不仅包括切图命名规则，还包括文件整理规范。
文件整理的好处
我在说一件事的时候，喜欢将原因或者自己的经历先交代出来，那样大伙也看得更明白，知道为什么要这样做。
刚工作的时候，为了省事，于是将所有的图层都随意摆放（针对的是sketch软件进行讲解的，Photoshop的应用同理），有时候实在是太多了就进行群组，英文叫group，有点像昨天发的开源项目源文件的样子。如下图：
可后来，渐渐发现，这样随意的做法在做方案的过程中看似节约了时间，实际上是浪费了时间。
为什么这么说呢？因为作为设计师，基本上没有一稿过的情况出现，方案都是同PM、同部门其他设计师、开发商量后一步步定下来的，所以反复更改的情况肯定存在，并且可能拿出以前版本的文件进行参考。那么对于文件来说，总是需要寻找、选定、更改各个版本号以及各个图层，如果时间一直浪费在寻找上面，真心划不来，无意义。
于是针对个人来说，整理好单个文件以及项目组的文件，是一件非常重要的事情，它提高了你的时间利用率。
后来，进了更大更规范的公司，所接触的项目就更多了。于是文件的管理，从个人查找自己的，变成了自己去查找团队的，以及团队查找团队公共的文件，有时候还要跨项目进行公用功能块，那就意味着有的文件是公用的。这样看来，文件管理也更加规范也更加重要，你能想象所有人像无头苍蝇一样到处乱撞去找文件，并且从各个杂乱的图层中找出某个图层进行修改的情况吗？
再者，有的软件非常依赖于sketch文件的整理，比方说动效原型的软件Flinto，sketch里面的图层按照什么规则进行陈列，利用sketch的插件导入到Flinto的时候，它就会长成什么样。如下图，左边是sketch的图层顺序，右边为Flinto的图层顺序。
软件这样设计的好处就是，很方便在sketch修改好文件之后进行导出。如果你的同事做的sketch杂乱无章，那么这项工作就必须由你自己来进行承担，那感觉真的是很想骂人。但反过来也是一样，你自己的sketch文件不整理好，也会给别人带来困扰，久而久之，别人也不太喜欢跟你合作。
当咱们将工作的场景放出来进行回顾的时候，就知道自己应该怎么做了。
文件夹的整理方法
一般用一个大的文件夹作为一个项目最原始的管理，还是拿千寻租房的项目来打比方。首先大的文件夹取名为该项目的名字“千寻租房”。首先我先针对有多个版本需要管理，并且UI和UX都需要进行接触的工作内容进行说明。文件整理方式如下图。
一般一个项目会涉及到以下几个内容的整理：
01 Wireframe ：low-fi（低保真效果图）文件的地址；
02 Visual Flow ：Hi-fi（高保真效果图）地址；
03 UI Kits ：图片资源输出的地址（比如说icon）；
04 Documents ：不是产品文档，而是APP里面需要的一些文档，比方说《服务条款》等；
05 App icon：APP的icon在各个平台上需要的尺寸图和它的源文件，尺寸常备1024x1024px，512x512px，167x167px，152x152px，120x120px，80x80px，58x58px（可以参考相关iOS规范）；
06 Video Templates：是有视频文件的情况下放置视频；
07 AppStoreScreenShot：专门为screenshot（即用来简介APP功能的页面，需要上传到各个APP的发布平台）进行准备的，因为安卓平台实在太多了，有时候每个平台规定的尺寸还不太一样，所以专门为它准备一个文件夹；
08 Lauch Card：因为在UI层面上需要耗费的时间比较多，一般在改版的时候放在比较靠后的需求，所以也可以单列出来。
而作为设计师，接触最多的就是01、02、03，所以将他们三个放在最前面，这也是给文件夹进行编序的原因，所以看到从01到08，序列号是按照它们使用的频率和重要程度来进行排序的。
为什么不将03进行版本的区分？因为同一个APP，从1.0改版的2.0的时候，icon可能延续了部分1.0版本的内容，所以部分是公用的，如果再在上面进行分类，反而程序员进行查找的时候要去翻多个子文件夹，反而不太方便。设计师只要告诉程序员所用图片的名字，程序员可以直接根据单个的icon路径，直接在里面进行提取。当然这也只是其中的一种解决方案。
每个版本又可以进行功能块子文件夹的分类，比方说上图中的这一部分。
Archive是用来放历史文件的，对于设计师来说历史文件是不能丢的，说不准哪一天老板就说“还是改回第一版吧。”你懂得~
以上是针对工作内容综合性比较强的同学进行设计的文件整理方式。倘若有的同学工作内容比较集中，比方做单做UI或者单做UX的，那么文件的整理方式也可以进行如下进行整理。因为内容比较单一，所以只需要进行版本号进行区分也行。
文件夹的命名方式是“项目名 版本号”。比方说1.0版本的千寻租房项目，那么命名就是“千寻租房1.0”，如果有平级的2.0版本，就在它平行的下面再建一个文件夹叫“千寻租房2.0”。那么无论找什么版本的文件都一目了然。
Sketch文件的命名以及它的图层的整理
1. Sketch的命名规则
Sketch的命名如上图可以看出，“项目名字功能块版本号_修改日期”，比方说在5月5日做的千寻租房1.0版本的首页，那么它的命名就是“千寻租房_index_1.0_0505”。加上日期是为了方便别人和自己查看哪个是最新的版本，有时候在查找历史文件时也能起到帮忙回忆的作用。
还有一点就是一般做项目的时候会给项目取一个英文的代号（特别是在跨国项目中，方便不同文化的人进行沟通），所以，在sketch命名中也多用英文进行命名。（英文不好的，用Google翻译或者有道翻译都是不错的选择，据我经验，三个月之后自己就习惯了）
2. Sketch的Artboard（画板）命名
作为新手我们很容易出现这样的Artboard的排布，如下图。
然后我们再来看看一个成熟的设计师它的Artboard的排布与命名，如下图。
我们可以发现，它的命名是由“代号-模块-功能”这样的结构而组成。先来解释一下，为什么会有代号这个存在，比如图中的“MR-1”与“MR-4”。
因为真正定稿后的sketch是需要与开发工程师进行开会商讨过稿的，一般这样的会议，会将sketch文件投影到一个屏幕上。而开发童鞋们，有什么问题需要指出的就直接说，“MR-1-1与MR-1-2有疑问”，而不用费力去说，“某某模块从左数第一页和第二页有疑问”。如果是远程会议，这样的代号更方便团队之间进行交流。所以一般都会为每个Artboard编一个码，并且一个代号表达一个模块，比方说上图中“MR-2”表达的就是“ManualHL”的模块。
另外Artboard命名完成之后，需要将所有的Artboard按照序列号排好，相同模块内容的需要放在一起。如下图：
还有一点需要注意的是，在sketch文件里面，为了将页面跳转流程表示得更加清晰，设计师会在最顶层加一个额外的Artboard，主要用来画流程线，和一些信息备注。如下图Flow&Note的Artboard。
3. Layer（图层）命名
Layer的命名，其实是涉及到单个Artboard的图层的整理方式。整理思路是，按照页面的内容先分几个大块，组成大的文件夹，然后再在每个文件夹下面将图层顺序排列好，按照图层内容进行命名。大文件夹和layer的命名尽量以文件夹内容和layer内容为依据，如下图Search的整理方式。
其中还涉及到icon的命名方式，icon最完整的命名方式为“模-类别-功能-状态”，比方说上图中的放大镜一样的search icon，它就可以用search_icon_input_gray，来表述，当然如果整个方案中只有一个这样的icon的话，觉得累赘也可以直接命名为icon_search。依情况而定，可以灵活变通。常用的模块、类别、状态如下图。
4. Symbol组件的命名方式
symbol（组件）的出现大大提高了设计师使用sketch的效率，以前改一个颜色需要全局修改的任务现在一键全部搞定。没有使用过sketch的童鞋可以先去尝试一下。
而symbol的命名如果规范好了，也会给自己带来很大的便利。一是在插入symbol的时候找起来特别方便，二是在导出图片的时候会自动分类成文件夹归纳好。如下图。
symbol在命名的时候会用“/”隔开去进行分类，比方说“icons/general/bringsensorclose”，意思就是在“icon”文件夹下建了一个子文件夹“general”，在“general”下有个icon名字叫bringsensorclose。导出后图片会按照这样的规则进行排列。并且在整理symbol的页面时，也需要遵循Artboard的文件的整理方式，即将同一个类别的symbol放在一起。
5. 导出图片的处理
一般咱们在做图的时候采用2倍的屏幕，多用750x1334px尺寸去进行方案的绘制，因为这个屏幕在市场上的占有率是相对来说比较大的。而在导出icon图片资源的时候呢，习惯上需要将@2x、@3x的图片都导出，在sketch的右下角会有这样的图片导出设置，如下图。
当然有的开发只要一倍的图，所以需要提前跟开发商量后再进行导图。当然如果图片过多，可能占用内存比较大，可以下载ImageOptim进行压缩。
到这里，文件命名的规范终于整理详细了。大到版本号文件夹的整理，小到icon命名的规范。总结一下规律，原则就是以内容为出发点，在脑海中划出层级关系，进行归纳分类，方便自己也方便团队其他人能顺利找到自己的资源，让合作效率更高。