前端，真的是让我哭笑不得的职业，从几年前作为打酱油的理想职业到现在的热门职业，无疑在这个过程中，门槛变高了，而且还是非常高。一大堆的框架和库，像什么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等这些技术栈，其实我们就已经选择了一整套的现成的架构，视图写在哪里、接口调用写在哪里、路由写在哪里等等的做法都已经有很成熟的范式给我们运用。

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

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