2016的最后一天，多多少少都应该总结一下这一年的得失，哪里做的好，哪里需要改进，记一笔，或许将来会用到呢。
毕业差不多半年了，一直是一个人在负责公司项目的前端开发与维护，当时公司希望前后端分离，提高前端的开发效率和后期维护的便捷，所以自己在经过一番调查后，决定采用SPA的模式，其主要原因还是阿里中途岛的那样的东西，我们没办法搞出来。
项目不需要兼容IE8及以下的浏览器，所以在选型的时候果断选了Vue.js那一套的东西，因为react之前也有了解过，上手的确没Vue来的快。
除去旧项目的维护时间，使用vue也有三个多月了，写一写这段时间来的使用心得吧
1. 如何划分组件和模块
组件化开发已经是谈了很久的东西了，在没有实战经验之前，看看民工大哥还有一些其他前辈写的博客，感觉这东西真的好牛叉，太好用了，但真当动手开始做的时候才会发现，其实并没有想象的那么简单和美好。具体的问题可以参考这篇文章Vue.js实践。
在组件的划分上，我把比较笼统的组件（components）分成了部件（widgets）和模块（modules）两个部分，部件主要是一些功能型的东西，而模块则是通过UI样式去定义。
我们从源头分析一下，一个网站是通过很多页面组成的，而每个页面有包含了不同的块，每个块则是通过不同的元素构成，这些元素我们可以把它想象成部件，也就是页面的最小构成单位。
但是在实际的开发当中，我并没有把所有元素都写成部件，而是一些功能型并且会重复使用的元素，才会写成部件，比如下拉框、切换开关等
而对于模块，则是包含了多个元素，里面也可能会存在部件，比如：
不管是部件还是模块，其目的都是为了复用，都可以统称为组件，之所以要这样划分成两个类别，是为了层次更加清晰，职责单一明确，更容易管理与维护。
当然，并不是所有UI样子差不多或者一样的地方都会把它写成组件，比如：
这两个导航，样式都一样的，但是用一个通用的样式或许会比写一个组件更加方便，这样就能减少一个组件的数据处理了。
2.组件样式
以前最头疼的就是class命名了，不过很庆幸的是Vue以自己的方式实现了shadow DOM。利用shadow DOM，使用BEM的命名方式，再配合单一职责的样式划分，再也不用担心class如何命名了。
使用BEM规范的命名方式的好处我这里不多说，大家可以自己百度，但是缺点就是class名往往可能会出现好长一串，这时利用shadow DOM可以很好的解决这个问题。
所有的模块里面所包含的元素无非也就那些：header、navicat、title、list、item、text......在开发的时候我写了一个规范，BEM三个部分分别都由哪些来构成，基本能满足所有的模块，几遍模块里有乱七八糟的一堆元素。后面会贴上命名规范。
使用单一职责的样式主要是为了解决组件组合拼凑的问题，在实际开发中，几遍看上去功能一样，UI也基本相同的地方，但是UI设计人员也可能会做出一些让人很郁闷的图，使得组件的呈现和布局样式不同，更别说是用在功能内容都不一样的地方了。
这个时候为了更好、更简单清晰的实现布局，变会使用一些单一职责的样式，比如：
就像这三张图，明明就同一个东西，非要搞差异化，如果这些都写在一个组件里，并不是不行，但是却很麻烦，但是如果我们组件写好一个基础的样式，另外的直接通过添加单一职责样式的class名，这样就方便多了。当然最好还是和UI同学商量，保持UI的一致性原则，不要为了自以为的好看，闭着眼睛乱画图。
当然，在同一个组件里的样式肯定还是需要通过prop之类的操作，但是在外部的布局和展现方面，我们可以在引用组件的时候，直接添上需要的class名就行了，这里不展示具体代码了。
3.工程结构
直接上图吧，实在不想写了，着急回家啊。
assets文件夹里的less文件夹放的就是一些单一功能的样式，比如layout.less文件里：
/* 上外边距 */ .mt30 { margin-top: 30px; } .mt60 { margin-top: 60px; } /* 右外边距 */ .mr30 { margin-right: 30px; } .mr70 { margin-right: 70px; } .mr90 { margin-right: 90px; } /* 底外边距 */ .mb20 { margin-bottom: 20px; } /* 左外边距 */ .ml30 { margin-left: 30px; } .ml40 { margin-left: 40px; } .ml70 { margin-left: 70px; }
components文件夹里的就更清楚了，widgets放一些公用的小部件，modules里放公共模块，而pages里就是各个页面了。
规范明后天再来贴。。。先回家了，实在坐不住了