模块化

作者: 不良怪兽 | 来源:发表于2015-01-08 16:07 被阅读117次

    面向对象的css有两个主要原则:separate the structure from the skin,separate the container from the content。

    第一个原则体现在模块化思想可以理解为,模块的设计制作和布局框架本身相分离,意味着你的模块不能只为某个布局而编写样式,像微博这类存在换肤功能的产品更是如此,如果模块在不同的皮肤样式下需要另写很多样式甚至是修改结构的时候,这个模块的制作就是失败的;第二个原则说的布局与内容的分离,布局中某个位置不必只能放置某种内容,反过来可以理解为模块的灵活性和复用性。

    其次遵守团队协作开发规范原则。

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

    按结构呈现形式划分模块的原则。

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

    模块稳固性原则。

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

    模块自适应性原则。

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

    Margin-bottom原则。

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

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

    设计必须严格遵循栅格化。

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

    产品、设计与交互的规范统一。

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

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

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

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

    相关文章

      网友评论

        本文标题:模块化

        本文链接:https://www.haomeiwen.com/subject/ksftxttx.html