模块化开发思想

Posted on  2014 年 3 月 19 日  by  荒漠千蝶

在网站的初始开发阶段，当你拿到最初的psd设计稿时，你是如何下手开始的呢？

你是依据什么划分网页的结构的？

你将依据什么如何提取网页内部的公用样式呢？

 

 

模块化的布局，最大的好处，便是易于开发和维护。更好的响应需求的变更。模块之间不相互依赖，又有一定的共性。

模块化的布局通常应用在大型的互联网网站开发中。

它的网站架构更需要的是在合理的嵌套中保持最好的健壮性，可拓展，易维护性。

 

例如：

你是否曾经经历过改版时部分功能的删除与修改，而此时你将要费心费力的去寻找此部分功能的htm和css代码，而css又有可能分布在不同的css文件中。你从不敢轻易删除一段样式的代码，因为你怕别的功能也应用了此段代码。

如果，你接受的是另一个人开发的项目，那么恭喜你，你每删除一段代码都将战战兢兢。。如果你不删除此段代码，长此以往将留下一大段的“历史遗留问题”。

例如：

你是否曾经经历在开发过程中，一个class的类名被命名的又臭又长，因为如果不这样的话，你将有可能跟其他的部分的class产生冲突，或者样式被覆盖。

你是否曾经看到过一段样式的代码。如.title 。。你有点记不起它在什么地方应用过，却又不得不留着它，并且在你以后的开发过程中，绕开.title的命名。

………

 

而对于我们这些有代码洁癖的的程序猿们，都希望看到整齐，有序的代码。并且希望我们的代码，每一行都不需要冥思苦想而能够轻松的知道它的作用和应用场景。

 

 

一个完整的网页，应该是由多个模块组成的。

例如头部的topbar，底部的copyright，内容的新闻列表，图片列表，侧部的热播排行等，他们都是一个模块，他们独立的展示了一块自己的功能。

如下图：

在模块化的布局中，有模块文件和模板文件。

在开发的过程中，将把这些模块提取出来。为其单独建立一个文件，为模块文件，而引入了这些模块的页面，为模板文件。。

请看下图示例：

模板文件：（~~~~(>_<)~~~~ 原谅博主不会画结构图，只能直接上代码了）

模块文件：

 

这些模块将有一个唯一的id属性是模块名，一般为文件名。

在网页开发过程中，非常不推荐id使用在除文档架构层以及除标识模块名之外的地方。因为除模块名之外，基本没有永远唯一的，不变的功能。

这些模块将有一个公用的class标识”g-mod”来标识他是一个独立的模块。

g-mod可以没有任何样式，它的存在仅仅是在网页结构中标识一个模块。

那么一个模块内部的结构又是什么样的呢？

首先，模块必定要有头部，我们为头部起一个名字叫.hd 。

头部中必定包含一个title。有人会问，如果没有title该怎么办，没有title只是在页面的展示中没有一个明显的标题，但是模块本身是要有标题的。

我们可以将此标题写在页面中，并且用css将其隐藏，这样做的好处是在某些辅助阅读工具在抓取我们的网页时，文档的大纲会清晰明了。也会使我们的网页更加语义化。

其次，便是模块的主体部分 ，我们为其起一个名字叫 .bd。

我们会将模块的大部分内容写在此处。

然后，是模块的尾部，我们可以把模块的一些次要内容，花边类的东西放在这个地方。 我们给它起名字叫 .ft。

如果没有这部分，我们可以不要模块的尾部。

那么，一个模块的结构图如下：（~~~~(>_<)~~~~ 原谅博主不会画结构图，只能直接上代码了）

 

这个时候，可能会有同学觉得，如果所有的模块都这样命名，是否会有样式冲突？

答案是不会。

我们在写css的样式的时候，每个模块的样式，都会在样式前声明自己的“命名空间”。所以不同模块内部的相同命名的元素样式不会相互覆盖与干扰。

例：

 

说到命名，又想絮叨几句，

模块的ID名，通常要完整，最起码通过模块的ID命，可以定位到是哪个模块。是做什么的。

而样式的class名，最好是要多简洁有多简洁，不要带上位置，模块的信息，避免一切的冗余。在命名的过程中不必担心与其他模块的命名相冲突，又有那么一点点语义化。

这样我们可以通过阅读一行css，而快速的在脑海中知道，这一行的css是对应哪里的样式。

如#apprise .list{}，我们通过读这一行样式，就会知道，此页面中有一个“评价”功能的模块，有一个列表。而#apprise li .date{},我们就会知道这行css是为了“评价”模块的列表中的时间信息所写。

在上面的图中，我们会看到，在模块化的布局中，css的写法也会实现类似“封装”的视觉效果。在我们需要更改某个地方的时候，也会更加快速的定位到这个地方的样式。

 

换一种说法就是我们不希望直接出现

.bd{} ;

.title{};

.name{};

这样的样式。因为这样的写法让我们茫然，让我们不知道他被哪些地方用到过。而且占用了.title,.bd这样的命名，会让我们下次不敢随意在页面制作的过程中使用这几个类名。

而我们希望的是

#crumb .bd{}

#curmb .title{}

#newslist .name{}

这样的方式，让我们一看就知道他大概会出现在什么位置。

有人会说，这样会平白无辜的在每一行样式前面多了一层深度。影响性能的。

但是，我们现在的电脑，已经不是N年前的486，我们现在的浏览器，已经不是N年前的IE5。多这样的一层嵌套。根本不会影响多少性能，却使我们的代码具有更好的健壮性和阅读性，在大型的互联网站开发中，版本不停的升级迭代。代码的可维护性需求远远高于性能。

 

那么，如果真的有公用的部分该怎么办呢？

如果是模块和模块之间有很大的相似度，我们可以直接写一个公用的模块。如：

/* g-newlist for module news1 , news2 */

.g-newlist{};

.g-newlist .hd{};

.g-newlist .bd{};

.g-newlist .ft{};

在模块文件中我们可以如此使用。

<div id=”news1″ class=”g-newlist”>…….</div>

<div id=”news2″ class=”g-newlist”>…….</div>

其中g-newlist 中的“g-”为global的缩写。当我们看到”g-”的时候，我们马上会知道，它是一个全局的样式。基础的类。

注释不可丢，一个公用的模块样式，要注释他为哪几个模块服务。

如果这两个模块有相似，又有所不同，都带了一点点个性化的东西，该怎么办呢？

大家知道，id的优先级是比class高出一个山坡的。

公用部分：

.g-newlist{};

.g-newlist .hd{};

.g-newlist .bd{};

.g-newlist .ft{};

个性化部分：

#news1 .ft{}

#news1 .ft .link{}

#news2 .bd{}

是不是完美解决了呢？

 

如果不是模块和模块之间有很大相似度，而只是一个小小的地方，如icon，在到处被用到。我们该怎么办呢？

我们可以写

.g-ico{}

.g-ico-sina{}

.g-ico-pptv{}

等等。。。。

具体公用样式的粒度大小，可以在开发的过程中自己掌控，不过，最好是在并非整个模块都十分相似的条件下，粒度越小，越少的依赖父级结构越好。

 

使用模块化的开发方式，使得一个团队内部每个人的代码都几乎是一样的，这样改起别人的代码来就像改自己的代码一样，改起自己的代码来更加的快速和得心应手。

让每个人都能读懂我们的代码。无论经过多少版本的迭代，我们只需要增，删，改对应的模块文件与其对应的样式，不会遗留一坨坨不知所云的代码。

 

———–END

番外：

模块化布局现在在大型互联网站的开发中非常流行。有的网站从始至终使用模块化的布局，而有的网站或多或少的应用。它最初起源于雅虎，而博主是在360时学习观摩而来。此篇博客为自己对模块化布局的理解和总结。也为纪念我们曾在一起工作的日子。

附上几个例子供参考，如

http://v.duba.com/

http://v.360.cn/

http://hao.360.cn/

http://css.doyoe.com/