记录一个前端架构的想法

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

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

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

记录一个前端架构的想法相关推荐

mess-cli : 一个前端微服务架构脚手架（beta版）
阅读本文需要较长的时间,本文介绍了微服务的概念.笔者心中的前端微服务,以及基于mess-cli脚手架,如何快速生成一个前端微服务架构项目什么是微服务? 相信了解过spring cloud的同学都知道 ...
生产可用：是时候来一个微前端架构了！
微前端的场景域在选择一个微前端方案之前,常常需要思考这样一个问题,我们为什么需要微前端.通常对微前端的诉求有两个方面,一是工程上的价值,二是产品上的价值. 对于工程上的价值,可以从一个三年陈的项目来 ...
要成为一个好的前端架构师需要做的事情
要成为一个好的前端架构师需要做的事情: 了解业务:全面调研当前业务和竞品的现状,充分理解当前渲染链路和节点,确认当前存在的问题寻找方案:预估未来发展的方向,尽可能多的了解相关解决方案或创新自己的方案 ...
使用开源微前端框架 Luigi 创建一个基于微前端架构的工程
官网地址微前端通常被称为"前端微服务". 它们允许您将大型单体前端分解为独立的.可扩展的.可以协同工作的独立部分. 微前端架构对于复杂的产品或拥有众多团队的公司尤其有用,可以帮助 ...
大型项目前端架构浅谈（8000字原创首发）
大型项目前端架构浅谈目录: 1.综合 1.1.使用场景 1.2.核心思想 1.3.切入角度 1.4.其他 2.基础层设计 2.1.自建Gitlab 2.2.版本管理 2.3.自动编译发布Jenkin ...
前端架构设计第一课 CI环境npm/Yarn
开篇词像架构师一样思考,突破技术成长瓶颈透过工程基建,架构有迹可循.你好,我是侯策(LucasHC),目前任职于某互联网独角兽公司,带领 6 条业务线前端团队,负责架构设计和核心开发.工程方案调研 ...
「前端架构」Grab的前端学习指南
原帖可以在Github上找到.未来的学习指南将在那里更新.如果你喜欢你正在阅读的东西,给它打一颗星吧! 公司是东南亚(SEA)领先的运输平台,我们的使命是利用公司最新的技术和人才,推动SEA前进.截至 ...
【微前端架构】微前端——功能团队中缺失的一块拼图
在任何合法的前端开发团队中,提高可扩展性和敏捷性很少会成为头等大事.在处理大型.复杂的产品时,如何确保快速.频繁地交付同时包含后端和前端的功能?像后端那样将前端单体分解成许多更小的部分似乎是答案.如果 ...
阿里浅谈大型项目前端架构设计
1.综合我在2年之前,写过一篇中小型项目的前端架构浅谈. 随着能力的上升,以及在阿里巴巴工作的经验,是时候写一篇大型项目的前端架构分析了. 本篇文章不会更多侧重于具体技术实现,而是尝试从更高角度出发 ...

记录一个前端架构的想法

记录一个前端架构的想法相关推荐

最新文章

热门文章