日期:2013-11-21  浏览次数:20927 次

网页制造aiyiweb文章简介:面向对象的css有两个次要准绳:separate the structure from the skin,separate the container from the content。第一个准绳体如今模块化思想可以理解为,模块的设计制造和规划框架本身相分离,意味着你的模块不能只为某个规划而编写款式,像微博这类存在换肤功用的产

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

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

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

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

当决定使用模块化构建的任务方式时,遵照某些准绳对模块化的顺利推进有很大的协助。

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

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

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

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

模块自顺应性准绳。指的是任何一个模块,都尽可能实现宽度和高度的自顺应,非特殊情况不要设置模块的宽高,采取这种准绳制造出的模块具有很好的即插即用功用,是高效完成页面拼合任务的重要前提。试想如果每个模块都定义了宽度,那么在不同的规划上你就必须重新定义每个模块的宽高或边距等属性来顺该当前规划。

Margin-bottom准绳。普通情况下,网页的规划都是从上到下的流式规划(多栏结构也可以看成各栏内的流式规划),所以,我们可以为每个模块统一预设margin-bottom,达到统一间距的目的,避免出现有些模块设置上边距、有些模块设置下边距的情况发生。(左右间距通常是由规划框架的款式设置)

在制定好团队的合作规范、恪守的准绳后,并不代表你就可以完全按你的思路启动任务,团队配合是多向的,除了团队内部,其他团队的支持也是不可或缺的,所以还需求以下两个前置条件:

设计必须严厉遵照栅格化。模块是独立的,但最终模块还是嵌套在规划中,由于我们的最终产出物是完整的静态页面,如何将分离的模块在最短的时间内,拼成一个符合设计师意图和产品要求的页面?栅格化是快捷的保障,在一个严厉按照栅格化设计的规划框架中,工程师只需求设置好规划框架款式和分栏的内外间距,后续的任务只需求把该页面所使用的模块嵌套进来,再调用对应模块的款式,由于模块的自顺应性,在所有模块预备充分的情况下,通常一个页面的拼合只需求几分钟的时间。

产品、设计与交互的规范统一。通常在项目的某个阶段,产品和设计在模块上的统一是比较容易的,但如果在同一个项目的不同阶段,尤其是在不同项目之间或不同产品之间要达到规范统一,就不是一件简单的事情。当规范统一性出现问题时,导致模块化只停留在某个项目阶段,每次添加新功用、添加新内容都需求添加全新的模块款式,移植性和复用性大打折扣,无法发挥应有的效果。当然,产品是持续改变和创新的,我们不能要求一个产品永远按照某个规范来进行设计,但我们还是应该共同努力寻求阶段性共赢的处理方案。在微博,经过各方长时间的努力,特别是交互设计对产品功用组件的统一,构建的WDL规范库对我们的模块化提供了很大协助。

依据实际情况来看,要达到所有满足的条件往往不是好事多磨的,特别是第二个条件的达成。但是退一步来说,即便不能使模块化在每个项目、每个产品中长期稳定的发挥它的最大能量,至少可以在每一次项目任务中获得模块化给团队带来的效率提升。

如果经过大家的努力,在所有条件都满足,而且模块化任务方式能在团队顺利开展的情况下,我们仍然可能会遇到各式各样的问题,一个无法避免的问题就是,产品功用升级惹起的模块变化,这时候是修正原有的模块还是另起一个新的模块?二是模块的划分程度,有些时候从模块的呈现和功用划分都比较模糊,有些时候对某些内容能否划为公用款式还是模块、还是页面独有内容都是见仁见智的;三是模块的分类,采取何种方式分类便于查找?类似这些问题还有很多,在不同的项目和情势下,需求具体问题具体分析,发挥团队的智慧,寻觅最合理的应对方案。

虽然在实施过程中可能会遇到各种问题和团队配合之间的阻力,但是当你逐渐顺应这种模块化团队构建的任务方式时,你会爱上它!而当你的团队高效地完成每个任务的时候,人们也会爱上你的团队!