那么，如不美观我们运用模块化构建的体例，优势在哪呢？也许在起头考试考试之处，需要一个顺应的过程，可能会使团队成员呈现之前近似我那时的设法，但当巨匠都顺应并谙练这种工作体例之后，必定能极年夜地提高页面构建的效率。

文章来历：微博UDC

按照现实情形来看，要达到所有知足的前提往往不是一帆风顺的，出格是第二个前提的告竣。可是退一步来说，即使不能使模块化在每个项目、每个产物中持久不变的阐扬它的最年夜能量，至少可以在每一次项目使命中获得模块化给团队带来的效率晋升。

假设有这样一个场景，团队接到一个页面很是多、工作量很是年夜的紧迫项目，第一个团队这么做：组长给每人分配几个页面，巨匠分头做完各自的页面，统一交付，对于分歧页面之间结构呈现相似的模块，细心点的团队可能谈判定让某小我写好，再复制给每个需要用到的人，不太在意的，则让每小我把各自页面上的所有内容都写一遍，已完成使命为重。第二个团队事先按照所有的页面划分公用或一再模块，再按模块独一性分配给每小我，有人负责搭建框架，有人建造模块，最后合并框架和模块，再按开发的工作打算，挨次交付页面。对比的结不美观是，因为第二个团队是多人配合建造一个页面，他们能以最快的速度产出开发需要的第一页面，而且越到后期越能发现页面中可重用的模块越多，最后整个工作时刻也许能比第一个团队缩减一半。模块的改暌姑不单是对本团队的工作时刻有很年夜影响，同样，对于下流的开发者来说，意味着他们也不需要为不异的模块重套代码或年夜头开发。此外，代码的冗余量、以及产物进级时两种工作体例的代码扩展性也浮现出很年夜的差距。再者，如不美观你的团队将要运用BIGPIPE或者LESS的开发体例，css的模块化是最好的配合手段，或者说是必需的。

曾经有一篇关于面向对象css的文章中指出，面向对象的css有两个首要原则：separate the structure from the skin，separate the container from the content。第一个原则表此刻模块化思惟可以理解为，模块的设计建造和结构框架自己相分手，意味着你的模块不能只为某个结构而编写样式，像微博这类存在换肤功能的产物更是如斯，如不美观模块在分歧的皮肤样式下需要另写良多样式甚至是改削结构的时辰，这个模块的建培育是失踪败的；第二个原则说的结构与内容的分手，结构中某个位置不必只能放置某种内容，反过来可以理解为模块的矫捷性和改暌姑性。

当抉择使用模块化构建的工作体例时，遵循某些原则对模块化的顺遂推进有很年夜的辅佐。

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

模块安靖性原则。我经常问新人一个问题，“你感受若何浮现你写的代码质量高，比一般人好？”，年夜年夜都人会回覆遵守语义化，减小不需要的嵌套，代码尽量精简。语义化和代码精简当然是评价质量的一个主要方面，可是我认为，代码是否考虑到数据遍历的合理性，是否考虑到dom节点的可操作性，是否考虑到因扩展造成的抗破损行，更能浮现一个页面构建工程师的水平。

模块自顺应性原则。指的是任何一个模块，都尽可能实现宽度和高度的自顺应，非奸细作况不要设置模块的宽高，采纳这种原则建造出的模块具有很好的即插寄暌姑功能，是高效完成页面拼合工作的主要前提。试想如不美观每个模块都界说了宽度，那么在分歧的结构上你就必需年夜头界说每个模块的宽高或边距等属性来适理当前结构。

按结构呈现形式划分模块的原则。这一点和模块化编程有较年夜的区别，凡是在编程开发时是以模块的功能来划分的，而在页面构建上，有时辰分歧功能的模块呈现的样式是一样的，为达到模块样式最年夜水平的改暌姑，就不能按功能来划分模块，简单来说，哪些模块外不美观结构一样，我们就可以把它们归为一个模块，以微博右侧模块举例，“可能感乐趣的人”和“举荐应用”模块的外不美观是一样，都是左侧一个图片、右侧文字和功能按钮，那它们就是统一个样式模块。

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

设计必需严酷遵循栅格化。模块是自力的，但最终模块仍是嵌套在结构中，因为我们的最终产出物是完整的静态页面，若何将分手的模块在最短的时刻内，拼成一个合适设计师意图和产物要求的页面？栅格化是快捷的保障，在一个严酷按照栅格化设计的结构框架中，工程师只需要设置好结构框架样式和分栏的内外间距，后续的工作只需要把该页面所使用的模块嵌套进来，再挪用对应模块的样式，因为模块的自顺应性，在所有模块筹备充实的情形下，凡是一个页面的拼合只需要几分钟的时刻。

Margin-bottom原则。一般情形下，网页的结构都是年夜上到下的流式结构若干好多栏结构也可以算作各栏内的流式结构），所以，我们可觉得每个模块统一预设margin-bottom，达到统一间距的目的，避免呈现有些模块设置上边距、有些模块设置下边距的情形发生。（摆布间距凡是是由结构框架的样式设置）

产物、设计与交互的规范统一。凡是在项目的某个阶段，产物和设计在模块上的统一是斗劲轻易的，但如不美观在统一个项目的分歧阶段，尤其是在分歧项目之间或分歧产物之间要达到规范统一，就不是一件简单的工作。当规范统一性呈现问题时，导致模块化只勾留在某个项目阶段，每次添加新功能、增添新内容都需要增添全新的模块样式，移植性和改暌姑性年夜打折扣，无法阐扬应有的效不美观。当然，产物是持续改变和立异的，我们不能要求一个产物永远按照某个规范来进行设计，但我们仍是应该配合全力追求阶段性共赢的解决方案。在微博，经由各方长时刻的全力，出格是交互设计对产物功能组件的统一，构建的WDL规范库对我们的模块化供给了很年夜辅佐。

说起模块化，也许我们首先想到的是编程中的模块设计，以功能块为单元进行轨范设计，最后经由过程模块的选择和组合组成最终产物。把这种思惟运用到页面构建中，也已经不是什么新奇事。相信很年夜一部门页面构建工程师都履历了这样几个阶段：第一阶段是在一个css文件中把多个页面按自己的习惯挨次年夜上往下编写样式，根基不考虑有无公悠揭捉式，以完成设计呈现为首要目的；第二阶段是提取分歧页面中的通悠揭捉式，如公悠揭捉色、停笔、按钮等，实现一些根基元素的改暌姑；第三阶段是提取公用功能模块，如导航、版权信息等，实现部门公用模块的改暌姑。

在制订好团队的合作规范、遵守的原则后，并不代表你就可以完全按你的思绪启动工作，团队配合是多向的，除了团队内部，其他团队的撑持也是不成或缺的，所以还需要以下两个前置前提：

如不美观经由巨匠的全力，在所有前提都知足，而且模块化工作体例能在团队顺遂开展的情形下，我们依然可能会碰着林林总总的问题，一个无法避免的问题就是，产物功能进级引起的模块转变，这时辰是改削原有的模块仍是另起一个新的模块？二是模块的划分水平，有些时辰年夜模块的呈现和功能划分都斗劲恍惚，有些时辰对某些内容是否划为公悠揭捉式仍是模块、仍是页面独有内容都是见仁见智的；三是模块的分类，采纳何种体例分类便于查找？近似这些问题还有良多，在分歧的项目和形势下，需要具体问题具体剖析，阐扬团队的聪明，寻找最合理的应对方案。

虽然在实施过程中可能会碰着各类问题和团队配合之间的阻力，可是当你逐渐顺应这种模块化团队构建的工作体例时，你会爱上它！而当你的团队高效地完成每个工作的时辰，人们也会爱上你的团队！