模块化开发

时间 2019-11-08

标签模块化开发繁體版

原文原文链接

一，为何要进行模块化开发（传统开发的弊端）html

1，命名冲突前端

　　在实际工做中，相信你们都碰见这样的问题，我本身测试好的代码和你们合并后怎么起冲突了？node

明明项目须要引入的包都引进来了怎么还报缺乏包？这些问题总结起来就是命名空间冲突及文件依赖加载顺序问题。举个简单的列子来解释一下命名空间冲突问题，看下面这段代码：jquery

test htmlwebpack

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
    <script src="js/module1.js"></script>
    <script src="js/module2.js"></script>
</head>
<body>

</body>
</html>
<script>
    var module=function(){
        console.log('I am module3');
    };
    module();
</script>

module1.jsweb

/**
 * Created by user on 2016/5/14.
 */
var module=function(){
    cosonle.log('I am module1.js');
}

module2.jsgulp

/**
 * Created by user on 2016/5/14.
 */
var module=function(){
    console.log("I am module2.js");
}

当运行test.html时结果输出：浏览器

显然是由于前两个JS文件里的函数名与html里面的一致而致使冲突，因此只会执行最后一个module()函数，在团队合做中你不会知道本身写的函数或变量等是否会与别人起冲突，这时候模块化开发就能解决这些问题。模块化

2，文件依赖函数

　　开发最基本的原则就是不要重复，当项目中有多处地方运用同一个功能时，咱们就该想办法把它抽离出来作成util，当须要时直接调用它便可，可是若是你以后的代码依赖于util.js而你又忘了调用或者调用顺序出错，代码变报各类错误，举个最简单的列子，你们都知道Bootstrap依赖jquery,每次引入时都须要jquery放在Bootstrap前面，一两个相似于这样的依赖你或许还记得，但若是在庞大的项目中有许多这样的依赖关系，你还能清晰的记得吗？当项目愈来愈复杂，众多文件之间的依赖常常会让人抓狂。下面这些问题，我相信天天都在真实地发生着。

1.通用组更新了前端基础类库，却很难推进全站升级。

2.业务组想用某个新的通用组件，但发现没法简单经过几行代码搞定。

3.一个老产品要上新功能，最后评估只能基于老的类库继续开发。

4.公司整合业务，某两个产品线要合并。结果发现前端代码冲突。

5.……

以上不少问题都是由于文件依赖没有很好的管理起来。在前端页面里，大部分脚本的依赖目前依旧是经过人肉的方式保证。当团队比较小时，这不会有什么问题。当团队愈来愈大，公司业务愈来愈复杂后，依赖问题若是不解决，就会成为大问题。

二，什么是模块化开发

　　模块化开发使代码耦合度下降，模块化的意义在于最大化的设计重用，以最少的模块、零部件，更快速的知足更多的个性化需求。由于有了模块，咱们就能够更方便地使用别人的代码，想要什么功能，就加载什么模块。可是也不能随便写哦。

三，什么是模块化？　

　　Node自带的规范 commonjs规范

　　Commonjs是node的规范，运行在服务端，不是浏览器端，若是使用在了浏览器端，须要使用对该文件进行打包翻译（借鉴工具browserify,webpack,gulp等）

书写模块的时候对外暴露接口module.exports={},exports.xxx=

引入模块 require（路径）

commonjs暴露的本质是一个叫exports的对象

Module.export={}和exports.xxx=

两者暴露的本质是同样的，都是exports的对象

两者暴露的本质是同样的，都是暴露一个exports对象

Commonjs是node的规范，但他是同步加载的，同步加载在浏览器端是一个坑，只要一个环节卡住了，后面的就无法执行。因此不建议使用，若是非要使用就须要编辑打包。

Web端

每一个js都是一个模块，每一个模块都必须有一个暴露接口，每一个js文件有一个全局的方法叫require()用于引入模块。