网站设计分析：模块化——高效重构

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

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

　　那么，如果我们运用模块化构建的方式，优势在哪呢?也许在开始尝试之处，需要一个适应的过程，可能会使团队成员出现之前类似我当时的想法，但当大家都适应并熟练这种工作方式之后，必定能极大地提供页面构建的效率。

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

　　当决定使用模块化构建的工作方式时，遵循某些原则对模块化的顺利推进有很大的帮助。

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

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

　　按结构呈现形式划分模块的原则。这一点和模块化编程有较大的区别，通常在编程开发时是以模块的功能来划分的，而在页面构建上，有时候不同功能的模块呈现的样式是一样的，为达到模块样式最大程度的复用，就不能按功能来划分模块，简单来说，哪些模块外观结构一样，我们就可以把它们归为一个模块，以微博右侧模块举例，“可能感兴趣的人”和“推荐应用”模块的外观是一样，都是左侧一个图片、右侧文字和功能按钮，那它们就是同一个样式模块。

　　模块稳固性原则。我经常问新人一个问题，“你觉得怎样体现你写的代码质量高，比一般人好?”，大多数人会回答遵守语义化，减小不必要的嵌套，代码尽量精简。语义化和代码精简固然是评价质量的一个重要方面，但是我认为，代码是否考虑到数据遍历的合理性，是否考虑到dom节点的可操作性，是否考虑到因扩展造成的抗破坏行，更能体现一个页面构建工程师的水平。

　　模块自适应性原则。指的是任何一个