记录一个前端架构的想法

前端，真的是让我啼笑皆非的职业，从几年前做为打酱油的理想职业到如今的热门职业，无疑在这个过程当中，门槛变高了，并且仍是很是高。一大堆的框架和库，像什么vue啦、react啦、angular啦、webpack啦等等等等。让人眼花缭乱

首先说说工做场景。目前作的项目是微信h5相关的，选择的是react那一套的技术栈。

如今前端js中，基本上已是普及了模块化的概念，从很早的seajs、requirejs到如今的es自带的模块化系统，已是愈来愈完善。

import request from 'superagent'
import { getToken } from "../../actions/global";
import { Toast } from "antd-mobile";
import { getQueryString, url_for, isWeiXin } from "../global_agency";
复制代码

都是经过import的方式很方便的来引用各个模块里面方法，但随着项目的不断迭代，文件愈来愈多，就很容易会出现下面这种状况。

这就形成了模块间的方法很混乱的传递。这样的状况在一开始是无伤大雅的，项目的前期，每一个模块的每一个方法的做用都是很明确的对应着项目的某个地方，依然保持着简洁。可是到了项目的中后期，就会出现破坏性的混乱。为何这样说呢？试想一下，当你某个方法使用的地方从一开始固定的一个变成了后来的不知道多少个，方法的迁移以及方法对应模块文件的迁移就会变得特别困难，虽然目前的IDE足够完善到已经能够作文件迁移后相应文件位置的批处理了，但或多或少的仍是让人不安。经历过的人会明白个人感觉！

混乱也意味着后期开发会愈来愈难，这也意味着代码耦合度高，准确的说应该是项目结构的耦合度高。一个模块处处可使用import引入使用确实很方便，却也给咱们带来了烦恼。咱们要作的就是经过增长模块传递的约束条件来让结构耦合度变低，固然代价就是失去这种彻底的便利，也能够说是规范这种便利。

那么咱们应该怎么作呢？一图胜千言！

如上图所示，咱们能够建一个中转文件，把咱们以为能够统一管理的但又比较分散的模块文件中的方法统一import到这个中转文件中，以下图：

这就有点像一个中介者模式，说形象点就像是飞机场、飞机以及工做人员的关系，假设每架飞机都有固定的工做人员，可是全部的飞机的工做人员都是由飞机场管理的，就算是这一架飞机须要另外一家飞机的工做人员帮忙，也是要经过飞机场来调控。

咱们的代码结构也是同样的道理。这样作的好处是在让结构清晰、可读性变强的同时，结构耦合度也下降了，到后续咱们还能很方便的在各个模块内部作一些适当的封装以知足更多的需求。就像一架飞机里面有机长、副机长、乘务人员等等，他们都有不同的工做职能。

以上就能够是一次架构提高，我相信咱们的平常工做中能够有不少这样的架构提高的机会。

文章题目是关于前端架构，那么有的同窗可能就会想:前端还须要架构吗？这个问题我本身也不知道，其实很早以前就据说过前端架构这个词，也只是只见过猪跑没吃到肉。我联想到前端架构以前的第一个问题是在我作的项目快要百八十个文件的时候，本身感受有点乱，虽然本身也还能够接受，毕竟项目也是在正式环境好好地运行着，可是若是这个项目交到下一个项目负责人手里，那他的日子就很差过了，在我这里的有点乱，到了他那里就会变成很是乱。因而我仍是为本身积积德，去整理一下。

因而乎我在网上下载了一本电子书，名叫《恰如其分地软件架构》，是以前有幸跟闲鱼的宗心交流的时候他推荐的（值得一提的是，大公司仍是有不少有你们风范的人的）。这本书里面都是传授架构的思想，并无很明确的架构的具体方法。因此这是一本好书，授人以鱼不如授人以渔嘛。

当咱们选择了诸如react、vue、angular等这些技术栈，其实咱们就已经选择了一整套的现成的架构，视图写在哪里、接口调用写在哪里、路由写在哪里等等的作法都已经有很成熟的范式给咱们运用。

每每在同一个项目面前，会有三种不一样的人：不作架构的人、选择作架构的人和完善架构的人。

选择了技术栈，咱们还仅仅是选择作架构的人，可是还不是完善架构的人。所谓的完善架构，也就是架构提高。就跟刚才说的，咱们已经选择的技术栈，选择了一套现成的架构，可是请相信我，这套架构绝对不是没有任何缺点了。咱们在作项目的过程当中，可能这也是发现现成架构缺点的过程，那么在这个过程当中，或者在这个过程以后，咱们可不能够想法设法去完备它？答案是确定的。怎么样才算完备？这就要问咱们本身了。