转载

前端工程架构探讨

回忆一下我们在工程开发中对目录结构的定义,一般分为两种,单页面多模块,多页面多模块。在单页面多模块的工程结构里,我们会考虑模块的复用性,比如:如何将公共的东西(样式、函数等)提取出来方便其他模块复用。在多页面多模块的场景中,也是一样,不过除了把全局共用的样式和方法提取到公共目录外,我们还会将多个地方都会用到的模块作为通用模块处理。

一、通常开发模式的问题探讨

下图是一个单页面多模块的工程目录结构图:

. ├── Gruntfile.js ├── package.json ├── build └── src  ├── base  │   ├── base.sass  │   └── global.js  ├── mods  │   ├── preference  │   │   ├── index.js  │   │   ├── index.sass  │   │   └── index.xtpl.html  │   ├── promo  │   ├── qr  │   └── response  └── index.js 

我们把源码放在 src 文件夹里面,公共的文件(iconfont 、sprite 图片、CSS 和 JS 等)放到 base 目录下,页面中的每个模块都会在 mods 下新建一个文件夹,使用 index.js 来管理模块的渲染。

// index.js define(function(require){  var Lazyload = require('lazyload');  var Preference = require('./mods/preference/index');  var Qr = require('./mods/qr/index');  var Promo = require('./mods/promo/index');  var Response = require('./mods/response/index');  new Response();  if(xxx){   new Promo();  }  Lazyload(function(){   new Qr();   new Preference();  }); }); 

这样的工程结构是十分通用,结构也比较清晰的,不过在模块的管理上,这里会存在两个问题:

  • AB模块存在较多的共用代码,我们有两种方式处理,一是将公共部分提取出来放到 base 目录下,二是 B 模块直接根据相对路径引用 A 模块。一旦业务上有需求,说 A 模块要下线,那下线之后,第一种方案放置在 base 目录下的代码就不合理了,第二种方案中 B 模块就不能用了,需要将 A 模块的东西部分迁移到 B 模块。
  • 问题 1 的逆过程:线上目前存在 A 模块,业务上需求需要添加跟 A 模块相似的 B 模块,如果想直接复用 A 模块的代码,一种方式是更小颗粒地分拆 A 模块,然后 B 使用相对路径引用 A,另一种方式是将 A 的共用代码提取出来放到 base 下。两种处理方式都有一定的工作量,而且还会出现问题 1 提到的问题。

其实说到底还是模块的耦合度过高,只要模块之间存在交集,一个模块的改动就可能会影响到其他模块。多人开发中,这里还存在其他方面的问题:

  • 并不是每个开发者对接手的项目都有一个全局的把控,下线一个模块时,会不太敢删除 base 目录下跟该模块相关的东西,甚至都不太敢删除这个模块,只是在 index.js 中注释了这个模块的初始化。日积月累,冗余代码便会渗入到项目的各个地方…
  • 修改一个模块需要编译打包所有的代码,这样的调试效率十分低下,而且这个模块出错,就可能造成整个程序的崩溃。
  • 代码历史版本管理的颗粒度不够,比如我修改了 A、B、C 三个模块,依次上线了三次,现在要回滚修改 A 的操作,如何处理?如果 ABC 三个模块都能够利用代码管理工具管理代码,那回滚就方便多了。

二、模块化处理

去耦合的方式就是让模块之间共用的东西减少,当模块之间不存在共用内容时,耦合度基本就是零了。

. ├── init.js ├── build └── src  ├── preference <git>  │   ├── index.js  │   ├── index.sass  │   └── index.xtpl.html  ├── promo <git>  ├── qr <git>  └── response <git> 

如上图所示,与之前的结构相比,已经少了很多东西:

  • index.js 初始化模块的东西不见了,多了一个 init.js
  • base 目录不见了
  • 每个模块都变成了一个 git 仓库

1. 脚本的初始化

先看看 init.js 在干啥:

// init.js var $mods = $("[tb-mods]"); $mods.each(functon($mod){  if($mod.attr("finish") !== FINISH_TAG) {   $mod.attr("finish", FINISH_TAG);   // 需要懒加载便懒加载   if($mod.attr("lazyload")){    Lazyload($mod);    return;   }    // 否则直接初始化   S.use($mod.attr("path"), function(S, Mod){    new Mod($mod);   });  } }); function Lazyload(){  // code here.. } 

init.js 不再对模块进行精确初始化,文档从上往下遍历,找到模块便直接初始化,如果需要懒加载就加入到懒加载队列,开发者不用理会页面上有多少模块,更不用理会各个模块叫做什么名字。

index.js 中 require 很多很多模块,每次添加一个模块或者删除模块都要改动这个文件,而是用 init.js 不会存在这个问题。

2. 模块的版本控制

<!-- index.xtpl.html --> <div tb-mods lazyload path="tb/promo/1.0.0"></div> <div tb-mods lazyload path="tb/qr/2.0.0"></div> <div tb-mods lazyload  path="tb/preference/2.2.1"></div> <div tb-mods path="tb/response/3.0.2"></div>

页面上的 DOM 就是标识,存在 DOM 属性标识就执行这个标识对应的脚本,执行顺序就是 DOM 的摆放顺序。

每个模块代码都使用单个 git 仓库管理,这样能够更好地追踪单个模块的修改记录和版本,也可以解决上面提出的问题(依次修改 ABC 模块,并上线了三次,如果需要回滚 A 模块,则 BC 模块的修改也要跟着滚回去)。

3. ABTest 需求

修改一个模块后,只需要修改他在 DOM 的版本号即可上线。如果遇到 ABTest 的需求,那也十分好办了:

<!-- index.xtpl.html --> {{#if condition}} <div tb-mods lazyload path="tb/promo/1.0.0"></div> {{else}} <div tb-mods path="tb/promo/2.0.0"></div> {{/if}} <div tb-mods lazyload path="tb/qr/2.0.0"></div> <div tb-mods path="tb/response/3.0.2"></div>

tb/promo 目前有两个版本,1.0.0 和 2.0.0,需求是两个版本以 50% 的概率出现,直接在 index.xtpl.html 做如上修改,程序是十分清晰的。

4. 公共文件的处理

那么,公共的代码跑哪里去了?其实我们并不希望有公共的代码产生,上一节中已经提出了耦合给我们带来的维护问题,但是一个项目中必然会有大量可复用的东西,尤其是当页面出现很多相似模块的时候。

1)模块的复用

一个模块的渲染,需要两样东西, 渲染壳子(模板) + 数据 ,渲染的壳子可能是一样的,只是数据源不一样,很多情况下我们可以复用一套 CSS 和 JS 代码,通过下面的方式:

<!-- index.xtpl.html --> <div tb-mods lazyload path="tb/promo/1.0.0" source="data/st/json/v2"></div> <div tb-mods lazyload path="tb/promo/1.0.0" source="data/wt/json/v1"></div>

在两个相似模块中,我们使用的是同一套 js - tb/promo/1.0.0 ,但是使用了两个不同的数据源 data/st/json/v2 , data/wt/json/v1

// init.js $mods.each(functon($mod){  if($mod.attr("finish") !== FINISH_TAG) {   //...   S.use($mod.attr("path"), function(S, Mod){    // 将数据源传入    new Mod($mod, $mod.attr("source"));   });   //...  } }); 

在初始化脚本中,我们将模块需要用到的数据源传入到模块初始化程序中,这样页面就成功的复用了 tb/promo/1.0.0 的资源。

2)CSS 的复用问题使用 less 的 mixin 处理

@a: red; @b: white; .s1(){  color: @a;  background: @b; } .s2 {  color: @a;  background: @b; } 

LESS 是 CSS 的预处理语言,上面的代码打包之后, .s1 是不存在的,只有 .s2 会被打包出来,但是两者都可以 mixin 到其他类中:

.s {     .s1;     .s2; }

利用这个特点,我们可以把共用的 css 都包装成类似 .s1 的 less 代码,模块中需要的时候就 mixin,不需要的话,放在那里也没关系,不会造成代码冗余。

3)JavaScript 的代码复用问题

页面级别的 JS 代码其实并不多,比如我们平时用的比较频繁的有 Slide、Lazyload、Tab、Storage 等,但这些东西都是以组件的形式引入到页面中。仔细想一想,JS 中哪些代码是需要页面共用的?相对整个项目的文件大小,共用的部分又有多少?

我们使用的基础库方法并不全面,比如:没有对 URL 解析的 unparam 方法,而这个方法用的也比较多,希望放到公共部分中去。回头想想,这样的小函数实现起来有啥难度么,三四行代码就能写出来的东西,建议放到组件内部搞定。这会造成一定的代码冗余,但是带来的解耦收益与费力写几行代码的成本相比,这完全是可以接受的。

页面共用的统计代码、错误收集代码、数据缓存方案、组件通讯代码等,这些量比较大、使用颇为频繁的内容,可以封装成组件,以组件形式引入进来。

这里还需要很多思考…

5. 模块之间的通讯

模块之间的通讯最让人纠结的是,A 模块想跟 B 模块说话,但是 B 模块还没有初始化出来。所以我们需要引入一个中间人 S,每个模块初始化成功之后都去问一问 S,有没有人给我留言。

// B 给 A 留言,如果 A 存在,则直接将 msg 发给 A // 如果不存在则送入 S 的消息队列 S.tell("A", {  from : "B",  msg: {} }); // A 模块初始化的时候,获取其他模块的留言 S.getMessage("A", function(msg){  // dosomething... }); 

三、小结

还有很多东西不在主题的讨论范围内,就不一一列举出来了。

项目开发参与的人越多,代码就越难维护,约束只是一时的,编程方式、编码格式等的约束并不能从根本上解决问题,一旦约束的点未覆盖,结构就会开始散乱,最后必然又会迎来一次整体的重构。

方法和结果不能改变习惯,所以我们应该从模式出发。

正文到此结束
Loading...