我的关于模块化的理解

我的对于模块化的探索

前一段时间咱们前端的项目组有一个分兴趣小组的计划.由于那时候整个小组只有9我的,因此就分了三个小组,分别是 `性能优化`, `模块化`, `新技术` 三个小组.

而我那进了"模块化研究"小组.因此嘞.研究模块化以及如何让项目的模块化更加合理和高效是咱们小组的主要目的.

首先，在实行模块化以前,得先巩固模块化开发的理论基础,由于理论是实践的基础。
只有这样，在过程当中理论与实践相结合,才有可能达到最满意的效果.

什么是模块化？

• 模块化就是为了减小系统耦合度，提升高内聚，减小资源循环依赖，加强系统框架设计。
• 让开发者便于维护,同时也让逻辑相同的部分可复用
• 模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立做用域、依赖管理、
  api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。

任何事物都有一个过程，那么模块化的过程通俗点讲就是：

模块化的过程就是：

• 一、拆分
  将整个系统按功能,格式,加载顺序,继承关系分割为一个一个单独的部分.
  注意:拆分的粒度问题,可复用问题,效率问题.如何这些问题处理的很差，就有可能出现不想要的后果。
• 二、概括
  将功能或特征类似的部分组合在一块儿,组成一个资源块.
• 三、总结
  将每一个资源块按找需求,功能场景以及目录约束放到固定的地方以供调用.

模块的历程

模块化的发展也是从草根一步一步走过来的。从最开始到如今成熟方案：

1. namespace
2. sass,less
3. AMD&CMD
4. html模版
5. grunt,gulp,webpack
6. FIS,YUI,KISSY

在亘古年代，机智的人们为了处理javascript的命名冲突，功能块管理等等，在js中使用了namespace。咱们能够说这是最原始的模块化管理模式。
以下：

// 使用namespace以前
var name={};
var name2={};

// 使用namespace以后
var nameSpace={};
nameSpace.branchOne={
    name:{}
};
nameSpace.branchTwo={
    name:{}
};

添加命名空间，达到拆分js逻辑的目的。

到了现代，处理css的模块化的有sass,less等工具。根据其提供的语法，即可以有效将css拆分为不一样的块。
还有随着AMD和CMD的出现，javascrip中namespace机制便已经被淘汰殆尽。不过目前咱们的项目组中那部分尚未迁移过来的老代码还在默默的使用着这种“古老”的方式。根据模块加载的工具类库，实现js逻辑的模块化加载的方式愈来愈称为主流。其中的好处你们能够查一查，不在这里就不赘述咯。
可是，最重要的一点必需要提比namespace更加利于维护和复用。
在html中也存在着各类前端和后端的模版。就像php中的smarty(咱们如今就在用)。前端中的juicer，underscore等等。它们一样的也能够将html按功能特色拆分抽离为单独的html块。
不过，上面的只是将js,css,html单独的进行进行模块化处理，并无一个统一的完整的实现功能模块划分，而spm，webpack这些工具偏偏作了这些事。它们能够将js，html，css以及其余静态资源按照开发者的意愿拆分为单独的模块，抽离的也更加完整。
上面的工具虽然能够帮助开发者们完成模块化，可是它们也仅仅只是一个单独的模块化工具，并无造成一个十分红熟的前端模块化方案。而fis,yui,kissy这些框架提供了囊括上述所有的功能。能够帮助开发者实现从头至尾的模块化。

此外，须要注意的是，前端的模块化并不该该只专一于某一项(js,css,html)的模块化，而应该是对项目总体进行解耦，抽离，组装。从而达到项目总体模块化的目的。

如何实现？

由于模块是按功能进行分类的，因此能够先将模块分为两类：

• 公共模块(用于促进代码复用)
• 业务模块(用于提高可维护性)

目前，咱们产品的V3版本的模块是经过：

1. 把耦合密集的归为一个模块
2. 模块间经过固定的接口交互
3. 模块内部实现自由发挥

这3个规则来区分和调用的。

主流的模块化是什么?

什么是主流的模块化哪？我接下来就用咱们项目组用依赖fis的fisp来粗略的说一下fis的模块化。

一、html的模块化分割

将偶合度比较高的页面片断进行单独拆分,模块布局做为公开的接口,进行html片断的继承 复用与拼装.
每一个单独的html片断使用单独而且对应的css片断,html中的图片能够按照相关性放到模块文件下的一个单独的图片文件夹里.
举个例子：

当咱们在打开外链页的时候，右侧圈住的那部分就是一个模块。那么在html中，它的结构是什么哪？
咱们有一个base.tpl是一个最外头的模版，结构以下：

还有一个html的主要框架lqyout.tpl，

一个功能模块share.tpl

最后哪，就到了咱们广告的模块 personal.tpl，

细心的同窗可能会发现，这些结构是一层一层的嵌套的。有大到小的分割。由最外头(base.tpl)->主结构(layout.tpl)->功能结构(share.tpl)->具体广告模块(personal.tpl)
这样哪，就会有效的组织页面。

html模块化能够实现多人协同开发页面.各司其职.有效提升页面的开发效率,和维护成本. 能够有效减小文件冲突,文件错误.
其中，页面模块代码做用域的控制经过css文件来控制。某类具备高度耦合的页面使用自身的css文件。

二、css的模块化

根据视觉布局,定义通用的css 以及单个html片断css

三、JS的模块化

鉴于目前主流的模块加载器，fis也提供了一个模块加载器叫mod.js。用法和requirejs,seajs差很少。咱们会按照功能将js分割并放到对应的位置。针对于模块化加载fis有一点作的比较好
为了协调异步环境下模块开发与性能间的矛盾，咱们必须在工程阶段就具有依赖分析的能力，把具有依赖关系的资源进行打包。就算不打包，也但愿像 F.I.S 那样有个记录依赖关系的map.json，能够照单抓药，一次性地把须要的依赖项加载下来。

所以，在开发期解析模块依赖、合并代码、甚至重写资源路径都得在工程化的层面完成。工程化和模块化变成了容易耦合且不得不耦合的两个话题。

上文提到的基本的原理，真正实施起来仍是存在不少问题，模块粒度问题，公共模块与普通模块的区分，继承模块是否值得继承等等，页面模块如何划分。

• 首先，了解你的项目，经过画网站树状图了解你网站的整体结构和页面模块。
• 其次，理清结构逻辑和视觉逻辑，结构逻辑就是看你的页面由那些模块组成，视觉逻辑了解可继承模块，布局逻辑（网格布局或者非网格布局）

目录结构:

按照类似性 能够将css html js 以及其余的静态资源放到一个一个文件夹中.固然,由于标准的确实,至于模块化的文件如何组织就见仁见智了.
咱们的目录是这样的：

一个单独的模块放到一个单独的文件夹里，这个模块的css，html，js以及其余静态资源也都放到一块儿，便于管理。
结构差很少能够像这样：

组件化:

组件化开发 ：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片断放在一块儿进行开发、维护，组件单元是资源独立的，
组件在系统内可复用。好比头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件好比下载(download)等。
一般业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。实现高内聚，低耦合.
就拿咱们的会员中心来讲，总体是一个大的组件。目录结构以下：

上述的模块化特色，目前咱们百度网盘使用的FIS已经将这些概念所有实现.并且作的还至关不错.
好了，正经的模块化介绍就到此结束。接下来，我为你们阐述一种另类的模块化.

换一种思路的模块化

就拿上面的百度网盘外链的单文件分享来讲:
每次有用户请求，上述的每一个html块都要通过php的smarty引擎在服务器端组合成一个完整的html在返回给浏览器端，不只如此，js、css以及其余静态资源都是.server端一天要作几十万次这种重复的操做。它好累！！！
不过，针对于前端开发者来讲,fisp作的已经足够了。它确实已经实现了完整的模块化。可是仅仅只是针对开发者而已。
有没有想过，对于浏览器来讲,这么一个一样的功能,每次都是从新加载一个内容和结构都差很少的html,若是能在这块作点什么东西,就像把模块化的思想用到浏览器上。那么，这个缺口是否是大有可为。
因此，实现针对于浏览器的模块化能够说是有必要的.从针对于开发者的模块化转换到针对浏览器的模块化.这是一个尝试的革命路线.

至于如何作。请听下回分解。。。