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

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

　　固然在实行进程中可能会碰到各种问题和团队配合之间的阻力，然而当你逐步适应这种模块化团队构建的工作方式时，你会爱上它!而当你的团队高效地完成每个工作的时候，人们也会爱上你的团队,成都企业网站建设!

　　设计必须严格遵循栅格化。模块是独破的，但最终模块还是嵌套在布局中,成都最大的网站建设公司，由于我们的最终产出物是完全的静态页面，如何将分离的模块在最短的时间内，拼成一个合乎设计师用意和产品要求的页面?栅格化是快捷的保障，在一个严厉按照栅格化设计的布局框架中，工程师只需要设置好布局框架样式和分栏的内外间距，后续的工作只需要把该页面所使用的模块嵌套进来，再调用对应模块的样式，因为模块的自适应性，在所有模块筹备充足的情况下，通常一个页面的拼合只要要几分钟的时间。

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

　　Margin-bottom准则。个别情况下，网页的布局都是从上到下的流式布局(多栏结构也能够看成各栏内的流式布局)，所以，我们可认为每个模块统一预设margin-bottom，到达统一间距的目的，防止呈现有些模块设置上边距、有些模块设置下边距的情形产生。(左右间距通常是由布局框架的样式设置)

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

　　(微博UDC原创博文，欢送转载并注明出处，欢迎订阅 )

　　模块牢固性原则。我常常问新人一个问题，“你感到怎么体现你写的代码品质高，比普通人好?”，大多数人会答复遵照语义化，减小不必要的嵌套，代码尽量精简。语义化和代码精简诚然是评估质量的一个重要方面，但是我以为，代码是否考虑到数据遍历的合感性，是否考虑到dom节点的可操作性，是否考虑到因扩展造成的抗损坏行，更能体现一个页面构建工程师的程度。

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

　　根据实际情况来看，要达到所有满意的条件往往不是一路顺风的，特别是第二个前提的达成。但是退一步来说，即便不能使模块化在每个项目、每个产品中长期稳固的发挥它的最大能量，至少可以在每一次项目任务中取得模块化给团队带来的效力晋升。

　　如果经过大家的努力，在所有条件都知足，而且模块化工作方式能在团队顺利发展的情况下，我们仍然可能会遇到各式各样的问题，一个无法避免的问题就是，产品功能升级引起的模块变更，这时候是修改原有的模块还是另起一个新的模块?二是模块的划分水平，有些时候从模块的呈现和功能划分都比较含混，有些时候对某些内容是否划为公用样式还是模块、还是页面独占内容都是见仁见智的;三是模块的分类，采取何种方式分类便于查找?相似这些问题还有许多，在不同的项目和局势下，需要详细问题详细剖析，发挥团队的智慧，寻找最公道的应答方案。

　　当决议应用模块化构建的工作方式时，遵守某些原则对模块化的顺利推动有很大的辅助。

　　在制定好团队的配合规范、遵守的原则后，并不代表你就可以完整按你的思路启动工作，团队配合是多向的，除了团队内部，其余团队的支撑也是不可或缺的，所以还需要以下两个前置条件：

　　说起模块化，兴许咱们首先想到的是编程中的模块设计，以功效块为单位进行程序设计，最后通过模块的抉择跟组合形成终极产品。把这种思维应用到页面构建中，也已经不是什么新颖事。信任很大一局部页面构建工程师都阅历了这样多少个阶段：第一阶段是在一个css文件中把多个页面按本人的习惯次序从上往下编写款式，根本不斟酌有无公用样式，以实现设计浮现为重要目标;第二阶段是提取不同页面中的通用样式，如公用色彩、图标、按钮等，实现一些基础元素的复用;第三阶段是提取公用功能模块，如导航、版权信息等，实现部门公用模块的复用。

　　模块自适应性原则。指的是任何一个模块，都尽可能实现宽度和高度的自适应，非特别情况不要设置模块的宽高，采用这种原则制作出的模块存在很好的即插即用功能，是高效完成页面拼合工作的主要条件。试想如果每个模块都定义了宽度，那么在不同的布局上你就必须重新定义每个模块的宽高或边距等属性来适应该前布局。

　　假设有这样一个场景，团队接到一个页面十分多、工作量无比大的紧迫名目，第一个团队这么做：组长给每人分配几个页面，大家分头做完各自的页面，同一交付，对于不同页面之间构造出现类似的模块，仔细点的团队可能会商定让某个人写好，再复制给每个需要用到的人，不太在意的，则让每个人把各自页面上的所有内容都写一遍，已完成义务为重。第二个团队当时依据所有的页面划分公用或反复模块，再按模块独一性调配给每个人，有人负责搭建框架，有人制作模块，最后合并框架和模块，再按开发的工作打算，顺序交付页面。对照的成果是，因为第二个团队是多人独特制造一个页面，他们能以最快的速度产出开发需要的第一页面，而且越到后期越能发明页面中可重用的模块越多，最后全部工作时光也许能比第一个团队缩减一半。模块的复用不单是对本团队的工作时间有很大影响，同样，对下游的开发者来说，象征着他们也不须要为雷同的模块重套代码或从新开发。此外，代码的冗余量、以及产品进级时两种工作方式的代码扩大性也体现出很大的差距。再者，假如你的团队将要运用BIGPIPE或者LESS的开发方法，css的模块化是最好的配合手腕，或者说是必需的。

　　产品、设计与交互的标准统一。通常在项目的某个阶段，产品和设计在模块上的统一是比拟轻易的，但如果在统一个项目的不同阶段，尤其是在不同项目之间或不同产品之间要达到规范统一，就不是一件简略的事件。当规范统一性涌现问题时，导致模块化只停留在某个项目阶段，每次增加新功能、增添新内容都需要增长全新的模块样式，移植性和复用性大打折扣，无奈施展应有的后果。当然，产品是连续转变和翻新的，我们不能请求一个产品永远依照某个规范来进行设计，但我们仍是应当共同尽力追求阶段性共赢的解决计划。在微博，经由各方长时间的努力，特殊是交互设计对产品功能组件的统一，构建的WDL规范库对我们的模块化供给了很大赞助。

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