这段时间做一个项目,其实项目本身很简单,页面表现和结构甚至是交互都是现有的,就是将现有的多个项目页面一些功能做一下重新的拼装组合。
看上去很简单,其实做起来非常痛苦。因为由于历史和前期项目开发的原因其实做这些拼装是很痛苦的事情。现在碰到的一个问题,要开一个C项目,使用A项目的头部、底部、布局,使用B项目的模块功能,同时A项目和B项目本身存在这千丝万缕的联系,很多功能A项目和B项目功能是重叠的,表现上又是很统一、但是又有细微的区别。A项目和B项目都相对独立,css样式也是很独立的,根据每个项目都有一套独立的样式。结果导致在项目维护中A项目改了,B项目也要改,得改2个地方不说。现在有出来一个C项目,又是A项目和B项目合体……,开发时候一些公用样式受到A项目和B项目影响,无法公用不说,维护成本可想而知。这个几乎让我崩溃。
如何既能提高开发效率又能降低维护成本是最为一个Tian开发工程师必须考虑的问题。正好前几天程序员和我讨论模板的问题,因为他们在开发C项目的时候也碰到了很多和我类似的问题。模板就是将页面的某部分分装成独立的版块,便于各个使用他的地方调用。那么我们的html和css可不可以按照功能模块或者展现模块来划分呢?答案显然是肯定的,至少在我们公司、我们网站由于页面表现和功能模块比较统一,这无疑给页面模块化提供了很好的萌芽环境。
css森林的鬼哥从去年开始就一直研究css模块化的思维,并发表可很多关于css模块化的文章()大家可在这里找到很多,我是每一篇认真拜读了一边,收益非浅,特别是基类,拓展类,虽然平时也常用但是实际的,但是没这么体系化的应用。但是我设想的网页模块化和鬼哥的css模块化又有比较大的区别,主要是根据我们公司的实际项目出发。
模块化是指解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个系统所要求的功能。模块具有以下几种基本属性:接口、功能、逻辑、状态,功能、状态与接口反映模块的外部特性,逻辑反映它的内部特性。在软件的体系结构中,模块是可组合、分解和更换的单元。
页面的模块话可能相对于程序简单一点,没有非常复杂的逻辑等一些外部特性,它主要是结构(html)、表现(css)和行为(js)上的组合拼装和代码重用。这样做的好处也很明显
- 提高代码重用率
- 提高开发效率、减少沟通成本,因为很多东西拿了就可以用,就像一个模板库,很多模块我只要拷贝或者引用过来就可以了;
- 降低耦合,只要建立好完整的模块和命名体系,基本不会去现耦合;
- 提高维护效率,所有地方只要改动一处就可以了,不用想我们A、B、C项目一样重复修改;
- 减少垃圾代码。我们通常会使用公用样式,其实很多页面只用了这个公用样式中的极少部分的代码,造成了很多没必要的垃圾代码。
看上去非常的理想。
今天我主要是记录了页面模块化的一些所见和所得,接下来我会记录和思考一下页面模块化具体实施。
当然页面模块化是老的一些思维和方式,由于很多原因这些老的思维和方式被淘汰或者无视,或者和现在思维发生了冲突。但是我们重新回过头去看看那些老东西,可能会有新发现。
沙发!
又发现几个错字
我觉着www.oocss.cc很不错,解决了我很多问题。可以高度重用,而不用将选择器罗列,只需要定义基类然后继承,这样我觉着更清晰
最近我也一直思考这个问题,
大概的想法是:
首先有很多widget例如tab grid .
大概定几套layout框架出来.
layout里可以自由搭配widget
icon和css 分开来针对 widget和layout
最后把所有的这些打包成主题文件
我已经在做了,但道路坎坷.做完再说吧.
“提高开发效率、减少沟通成本,因为很多东西拿了就可以用,就像一个模板库,很多模块我只要拷贝或者引用过来就可以了;”
引用是OK的,如果拷贝的话,就又会出现“改一个地方结果要动好多个文件”的情况了。
@Ven 是会存在这个问题,但是可以通过其他办法解决。我们公司的做法是:实行项目管理的办法,一个项目要引用多少模块和文件都保存在一个项目管理软件里,如果改动某一模块,引用该模块的项目的css,只要按个按钮就会全部自动生成,当然也可以直接上传。