前言

本文适用于开发中的业务级代码，打包后的代码优化等可参考其他文章

由于前端代码其实并没有严格意义上的类或模块的概念（哪怕是import与export也是非强制性的拆分），因此很多新手前端对于代码该如何拆分，如何设置独立的文件陷入了长时间的犹豫，博主仅以经验之道进行分享，如有不对请多包涵，并告知，本人加以改正

一、代码拆分的意义

其实代码拆分无外乎解决以下问题

过于复杂的逻辑
抽象公共的代码

我们不是为了拆分而拆分，是为了某一些优势进行的拆分
如果你没有意识到这部分代码是有必要拆分的，需要思考

这块代码很复杂吗？
这块代码在别的地方上可复用吗？

1.逻辑的独立性

用户的应用程序和数据库中的逻辑结构是相互独立的,当数据的逻辑结构发生改变时应用不需要改变. 逻辑独立性存在于外模式和内模式之间。数据的逻辑独立性是指数据与程序的逻辑独立性。

出处：百度百科

1）数据独立性

其实每一块独立的块，都可以使用一套独立维护的数据声明体系，如下

let index = 0
{
	let index = 1
}

因为本文以代码拆分作为重点，而非变量取名，故使用index作为变量名
上部代码仅为示意，当代码量突破百行时，此类问题会比较突出
当大量代码时，合理的拆分能够保证区间内的参数是独立于外界的，且尽可能不污染外界，避免导致一些奇怪的现象发生（数据污染）

2）程序独立性

·拆分出来的代码确保其逻辑是独立的，或者其所需参数是明确的

3.可维护性

确保拆分的代码便于修改、模块化和功能独立，当涉及某类逻辑变更时，其代码是一体的

二、如何拆分代码

其实前端代码文件拆分思路与类的拆分是极为相似的，本文借鉴了其他的一些类的拆分原则，进行了前端化处理，也是本篇文章着重描述的内容

1.将代码拆分的原因

便于复用

因复用性，将代码拆分是最为常见的一种拆分模式，例如前端的utils文件夹内的各个文件，都是根据经验或者积累所得的工具代码进行整合加以复用，在一些业务代码的开发时，可能会遇到某一些特质函数的编写会重复使用在多个地方，此时可以将此类代码进行规整剥离，拆分到一个地方进行统一管理

拆分前：
function test1(a,b) {
	if(a>b) return true
	return false
}
function test2() {
	let c = 1
	let d = 2
	if(c>d) return true
	return false
}
function test3(e) {
	let f = 1
	if(e>f) return true
	return false
}

拆分后：
function comparativeSize(a, b){
	if(a>b) return true
	return false
}

function test1(a,b) {
	return comparativeSize(a, b)
}
function test2() {
	let c = 1
	let d = 2
	return comparativeSize(c, d)
}
function test3(e) {
	let f = 1
	return comparativeSize(e, f)
}

现在因业务需求变更，需要将（a>b返回true，否则返回false）改为（a>b且b>5返回true,否则返回false），可以试着改一下
如果这几个代码片段存在于好几个地方呢？
你是愿意改一个地方还是改多个地方？

降低并隔离复杂度

当代码拆分到别的地方后，你可以短暂的不去管他们（当然，你需要去动此处代码时，你还是要管的），但是代码拆分后，你可以忘掉具体的细节，只知道对应的功能和结果，不必深入到文件内去看其运转流程。

无论复杂度是因为昂长的代码，还是陷入了可怕的数据声明，抑或是复杂的逻辑，这些内容都被隔离在另一个地方，就如同你看一本书时，可以略过一个字从无到有的过程，只去读这个最终结果。

当需要维护被隔离的代码时，应当不会对外部使用者产生影响，因为这些代码时被合理的隔离的。

隐藏实现细节

其实与隔离复杂度的思路一致的，一些处理某一类问题的代码是可以被隐藏起来的，因为他们太复杂了，不适合后面的人理清业务时去一点点扣细节，相反，他们可以读一下函数名或注释去了解这块代码在干什么，然后继续去理清下面的业务代码，至于comparativeSize这个函数具体干了什么？谁在乎呢，起码此时此刻，comparativeSize不是我需要看的重点。

限制变动影响范围

把最有可能变动的代码隔离出来（可能与常识违背，为什么不是把定型的代码隔离出来？）例如蓝牙连接等功能，将变动影响范围尽可能控制在少量的文件或代码块之中，避免不慎操作导致本不应该影响到的代码被影响到（明明要改comparativeSize就行了，却不小心在test3（e）代码块里又声明了一个e）

常量配置

const defaultInit={
        selector: "#tinymce",
        language_url: "/lib/tinymce/langs/zh_CN.js",
        language: "zh_CN",
        skin_url: "/lib/tinymce/skins/ui/oxide", //编辑器需要一个skin才能正常工作，所以要设置一个skin_url指向之前复制出来的skin文件
        plugins: 'link lists image code table wordcount media fullscreen preview paste contextmenu textcolor', //引入插件
        toolbar:
          'fontselect| fontsizeselect | bold italic underline strikethrough table fullscreen  | link  image media  | undo redo  | alignleft aligncenter alignright alignjustify | bullist numlist | forecolor backcolor | outdent indent blockquote | code | removeformat', //工具栏
        browser_spellcheck: true, // 拼写检查
        branding: false, // 去水印
        elementpath: false, //禁用编辑器底部的状态栏
        statusbar: false, // 隐藏编辑器底部的状态栏
        paste_data_images: true, // 允许粘贴图像
        menubar: false, // 隐藏最上方menu
        media_live_embeds:true,//视频的内嵌代码预览是否开启，为ture时富文本编辑框可实现预览功能
        
        file_picker_types: 'file image media',
        images_upload_credentials: true,
        fontsize_formats: "14px 16px 18px 20px 24px 26px 28px 30px 32px 36px", //字体大小
        font_formats:
          "微软雅黑=Microsoft YaHei,Helvetica Neue;PingFang SC;sans-serif;苹果苹方=PingFang SC,Microsoft YaHei,sans-serif;宋体=simsun;serifsans-serif;Terminal=terminal;monaco;Times New Roman=times new roman;times", //字体

      }
      export default defaultInit;

例如一些常量，或者与之相关操作，是可以独立出一个地方进行存储的，同时也相当于一种声明和保护——嘿！这里可是常量，你当心点！
当然，你需要考虑的不仅仅是常量的问题，也可以是对于常量的习惯操作，例如一些设计模式中所使用的基础函数，也是可以抽离出来的。

隐藏一些环境绑定

前端代码很多适合需要引入一些副作用文件，此时可以将相关的副作用进行归纳抽离，比较谁也不想读文件时，老是跳过一些没什么可读意义的代码

tinymceEnvironment.js

/** 集中引入相关副作用环境 **/

export * from  'tinymce/themes/silver/theme';

export * from  'tinymce/icons/default/icons';
export * from  'tinymce/themes/silver';
// 引入富文本编辑器主题的js和css
export * from  'tinymce/themes/silver/theme.min';
export * from  'tinymce/skins/ui/oxide/skin.min.css';
// 扩展插件
export * from  'tinymce/plugins/image';
export * from  'tinymce/plugins/link';
export * from  'tinymce/plugins/code';
export * from  'tinymce/plugins/table';
export * from  'tinymce/plugins/lists';
export * from  'tinymce/plugins/wordcount'; // 字数统计插件
export * from  'tinymce/plugins/media';// 插入视频插件
export * from  'tinymce/plugins/template';// 模板插件
export * from  'tinymce/plugins/fullscreen';
export * from  'tinymce/plugins/paste';
export * from  'tinymce/plugins/preview';
export * from  'tinymce/plugins/contextmenu';
export * from  'tinymce/plugins/textcolor';


index.js

import './tinymceEnvironment';//一句即可

清单

下面的清单是根据《代码大全2》的类的质量核对表，进行的前端化改善，我认为，本质上前端代码的抽离和类的抽离，应当是类似的。

你有把这些代码视为一个整体吗？他们有一个明确的输入输出值吗？
代码块有一个中心目的吗？他们是围绕这个目的生成的吗？
代码块的函数名或文件名合理吗？有没有表达出这块代码在干什么？
代码块有没有明确告知他在干什么？怎么用？
代码块足够抽象吗？可以在外部不必考虑他具体做了什么吗？可以把他当成黑盒子略过吗？
代码块提供的服务是否完整，不需要在外部提供额外代码进行“没必要”的二次加工？
代码块里有没有包含他所不需要的内容？例如一些声明后没有处理就扔出去的值？或者是另一块代码？
有没有考虑这一块代码是否是独立的，有没有保证他功能单一？
修改这个代码块时需要特殊处理外部的代码吗？
是否确认代码的输入输出已经是最少且必须的？
是否避免暴露过多的内容
是否尽可能的将实现细节隐藏起来了？
没有对外部代码如何使用它作出假设吧？
如果需要别的代码块，是因为什么？符合松散耦合吗？有确保引用的代码是最少且必须的吗？
是否只在绝对必要时才与其他的代码块相互协作？
如果代码块有入口函数，入口函数有进行数据初始化吗？
最重要的:你为什么拆分代码？为了复用？为了简单？实现了吗？

前端代码拆分的意义，以及如何拆分代码，文件拆分--前端教学文-f

目录

前言