说起模块化，也许我们首先想到的是编程中的模块设计，以功能块为单位进行法度设计，最后通过模块的选择和组合组成最终产品。把这种思想运用到页面构建中，也已经不是什么新鲜事。相信很年夜一部分页面构建工程师都经历了这样几个阶段：第一阶段是在一个css文件中把多个页面按自己的习惯顺序从上往下编写样式，根基不斟酌有无公用样式，以完成设计显现为首要目的；第二阶段是提取不合页面中的通用样式，如公用颜色、图标、按钮等，实现一些根基元素的复用；第三阶段是提取公用功能模块，如导航、版权信息等，实现部分公用模块的复用。

适才描述的第三阶段的体例已经包含了模块化思想，很多团队也都有一套成熟的模块化开辟方案。而我第一次听说模块化构建体例，是三年前在一家韩国互联网企业工作时，某些产品中要求使用一种称为UIO体例，模块化通用的功能模块或组件，以达到最年夜水平的模块自力性与复用性，那时团队中很多同事和我一样，认为这种工作体例约束了编码的自由性，过量的布局约束反而下降了工作效率，加上产品之间也存在不统一，最后并没有运用到整个团队。

那么，如果我们运用模块化构建的体例，优势在哪呢？也许在起头测验测验之处，需要一个适应的过程，可能会使团队成员呈现之前近似我那时的想法，但昔时夜家都适应并熟练这种工作体例之后，一定能极年夜地提高页面构建的效率。

假定有这样一个场景，团队接到一个页面很是多、工作量很是年夜的告急项目，第一个团队这么做：组长给每人分派几个页面，年夜家分头做完各自的页面，统一交付，对不合页面之间布局显现相似的模块，细心点的团队可能会约定让某小我写好，再复制给每个需要用到的人，不太在意的，则让每小我把各自页面上的所有内容都写一遍，已完成任务为重。第二个团队事先按照所有的页面划分公用或重复模块，再按模块唯一性分派给每小我，有人负责搭建框架，有人制作模块，最后归并框架和模块，再按开辟的工作打算，顺序交付页面。对比的成果是，由于第二个团队是多人配合制作一个页面，他们能以最快的速度产出开辟需要的第一页面，并且越到后期越能发现页面中可重用的模块越多，最后整个工作时间也许能比第一个团队缩减一半。模块的复用不单是对本团队的工作时间有很年夜影响，同样，对下游的开辟者来讲，意味着他们也不需要为相同的模块重套代码或重新开辟。别的，代码的冗余量、以及产品升级时两种工作体例的代码扩大性也体现出很年夜的差距。再者，如果你的团队将要运用BIGPIPE或LESS的开辟体例，css的模块化是最好的配合手段，或说是必须的。

当决定使用模块化构建的工作体例时，遵循某些原则对模块化的顺利推进有很年夜的帮忙。

曾经有一篇关于面向对象css的文章中指出，面向对象的css有两个主要原则：separate the structure from the skin，separate the container from the content。第一个原则体现在模块化思想可以理解为，模块的设计制作和布局框架自己相分手，意味着你的模块不克不及只为某个布局而编写样式，像微博这类存在换肤功能的产品更是如此，如果模块在不合的皮肤样式下需要另写很多样式甚至是修改布局的时候，这个模块的制作就是失败的；第二个原则说的布局与内容的分手，布局中某个位置没必要只能放置某种内容，反过来可以理解为模块的矫捷性和复用性。

其次遵守团队协作开辟规范原则。这个规范可以包含文件目录布局、文件和样式命名规范、图片sprite规范、模块划分和挪用规范等，例如我们对文件目录深度的规定、公用样式使用规定、模块的样式名唯一性规定、模块文件名和样式名必须一致的规定等等，确保所有人产出的模块是统一、规范的。

按布局显现形式划分模块的原则。这一点和模块化编程有较年夜的区别，通常在编程开辟时是以模块的功能来划分的，而在页面构建上，有时候不合功能的模块显现的样式是一样的，为达到模块样式最年夜水平的复用，就不克不及按功能来划分模块，简单来讲，哪些模块外不雅布局一样，我们便可以把它们归为一个模块，以微博右侧模块举例，"可能感兴趣的人"和"推荐应用"模块的外不雅是一样，都是左侧一个图片、右侧文字和功能按钮，那它们就是同一个样式模块。