前端有架构吗？

本文首发于 欧雷流。因为我会时不时对文章进行补充、修正和润色，为了保证所看到的是最新版本，请阅读 原文。

从事前端开发的你，不知有没有被问过：「前端有架构吗？」

问你的人的身份，多是你的 boss 或上司，多是后端同事，也多是前端同行；问你的人的目的，多是刁难，多是嘲讽，也多是请教。

前端开发

众所周知，作前端开发所依赖的核心技术就是 HTML、CSS 和 JS，就像好基友同样如影随行，咱们将它们仨亲切地并称为「三剑客」。

通过这二十多年，尤为是在 V8 引擎及 Node.js 出现以后，以「三剑客」为基础的衍生技术如雨后春笋般大量出现，前端及其关联社区与前端工程师这个职业获得了空前的蓬勃发展，甚至让不少人以为一个前端工程师不只仅能够作 web 前端开发，还能够写后端，替代客户端工程师——前端技术一统天下！

工做内容

除了作网页，前端技术还能应用于命令行工具、客户端应用、服务端应用、聊天机器人、爬虫、IoT 等场景。只要脑洞足够大，就不怕场景不够多。

然而，绝大部分的前端工程师在工做中都会接触到这些吗？

试想一下，本身的工做历程是否是这样的——

在一家 150 人规模如下的创业公司，可能业务还在摸索期，须要不断地快速试错以找到能够铆足劲儿去发力的点。这时前端团队也没几我的，可能就三五个吧，而且 leader 不是什么大牛，也没有一套方法论做为团队建设的指导，也许你是这个团队里实力最强的。

这个时期所须要的就是可以快速迭代产出成果，而后去验证是否有效。根本不会给你时间去思考、规划前端团队的发展方向与基础设施建设。若是特地花费时间去作这些，没准儿公司会认为你「游手好闲」，到时 KPI 打个不及格。

经历一段时间的焦头烂额，在此期间工程目录、代码提交极可能都很随意，而且没有 code review。有空闲下来回头一看，代码一坨一坨跟那个什么似的，实现与「优雅」这个词绝缘。

随着业务的快速发展，项目、应用愈来愈多，团队人数也愈来愈多，然而规范约定、基础设施依然几乎没有。在业务线作开发的前端，也不太会想着整个团队的工具统一，本身怎么爽就怎么来。最终致使一个团队用了多种视图层库、多个组件库，给收敛技术栈带来很大阻碍。

终于，公司的业务开始走上正轨，前端团队也已经有二三十人了，胸怀大志、急他人所不急的你以为再这样野蛮生长下去是确定不行的，靠堆人力去知足快速发展且多变的业务需求是很是低效且低级的方式，必需要有技术上的基础设施去支撑！即便公司层面不容许工做时间去作这种长远看来对公司是百利而无一害的事情，也要去作，就业余时间去作！

在全部基础设施中，最初级、最能直接体现出开发提效成果的，就是高度抽象的 UI 框架。通过了不知多少个的「下班后」和「周末」，可算搞出了个可以知足必定业务场景的，在本身负责的几个应用中初见成效。

正当你为本身所作的事情如指望中那样获得了收益而感到欣慰时，忽然有人冒出来质疑你所作的事情，而且有可能就是前端团队中的。还好有其余人对你作的事表示承认，以为有价值，让你有动力在这件事上继续下去。也许他是个后端开发，愿意去用，或愿意帮你在部门中推广。

你不断地给 UI 框架增长新的功能，并千方百计去改造旧系统。在公司拓展业务所须要的新应用和之前老应用的维护中，你所作的东西确确实实节省了很多人力和资源。在有新的一批后端开发入职时，还会邀请你在新人培训上给他们讲解如何使用你所开发的 UI 框架辅助完成工做。这结结实实地打了当初质疑你的人的脸。

后台系统页面的常见模式就是供数据 CRUD 的列表页、表单页和详情页，当把支撑这些场景的交互和数据处理的核心逻辑都已经抽象了以后，你发现再怎么完善 UI 框架也不会有像以前那样比较明显的效率提高，顶可能是优化了交互和开发体验，使功能更稳定而已。

你陷入了思考：「该作些什么才能继续为开发提效呢？」

以前作的 UI 框架，是对交互逻辑和数据逻辑进行了高度封装，并提供了大量的 CSS class 和工具方法。虽然使在作页面时能够少写不少 CSS 和 JS 代码，但对于 HTML 代码来讲并无减小。

貌似找到了该突破的点，但要怎么去作呢？

冥思苦想，你忽然灵光乍现，想起了本身曾经用过的基于「世界上最好的语言」开发的博客系统——WordPress。既而后台系统页面如此模式化，何不效仿 WordPress 将不易变的部分做为「主题」，易变的部分做为「文章」？

这样作会带来另一个好处，就是将页面代码数据化了，有什么纯前端的问题修改就只是数据修正，而不用走冗长繁杂的运维发布流程。往后若是公司有了本身的设计语言，再加入可视化搭建的特性，业务后台系统的开发和维护前端就不太用参与了！

理想状况下，产品经理用已有物料拖拖拽拽生成「原型」，该「原型」就是最终界面；业务功能肯定后，后端开发定模型、写接口，而后配置界面的数据展现。这样一来，业务系统迭代的整个过程当中，基本能够忽略前端这个角色了。

那么前端干什么呢？在这样的协做模式下，前端的主要工做就是完善物料库，而且让产品经理和后端开发使用起来更方便。这种提效方式所带来的收益，与开发 UI 框架相比，根本不是一个层次的，想一想都以为兴奋！

然而，理想的丰满遮不住现实的骨感。听到你的想法的人，要么质疑地问你一些问题，要么嘴上表示支持心理暗地讥笑——不想些怎么让业务发展起来的事情，成天想什么乱七八糟、花里胡哨的东西！

你以为内心憋屈，认为他们目光短浅，看不透本质。但为了本身所认为所坚信的「正确」，就算没有人在心理上或行动上有所支持，也要朝着那个方向努力，尝试作一把！

通过一段时间的折腾，你开始感到有些作不下去了。一方面是由于，虽然 Node.js 的出现让前端开发人员也可以开发服务端，但数据库等服务端开发领域所需知识和思惟方式匮乏，导致设计很不合理，写出来的程序也很差；另外一方面，公司层面不指望你投入较多的时间在短时间内对业务发展没有太大帮助的事情，就连 KPI 的指标设定都是很业务化的，等 KPI 评分时分数确定很低。

在这家公司里，你也算是「老员工」了，对公司的品性也较为深入了解，自觉本身所认为所坚信的「正确」在这里得不到认真对待，至少很长一段时间以内是，你甚是失望，甚至绝望。其实，你早如此感受，只是不肯面对，老是但愿本身的信念可以多多少少影响到组织的认知，然而徒劳。

从 UI 框架到页面数据化，在作这些事情时你都是独自一人、孤军奋战，突然内心感到一丝悲凉。你最终黯然离开，想去大厂里去看看，也许那里可以让你实现技术理想。

当你真正进了大厂，并且是个业务部门时，你会发现作的事情和以前并没太大差异，仍然是业务为重。不一样的是，可能你的领导和身边的同事，对你的想法是真心认同的，他们会尽力支持你想作的事情，并为你提供帮助。

你幡然醒悟：不管在小厂、中厂仍是大厂，只要是在业务部门，UI 框架、命令行工具基本就是在技术上所能作的极限，要想更上一层，就得在平台部门。

提效方式

前面屡次提到了「提效」这个词，它是什么？简单粗暴地讲，就是缩减业务需求的研发时间，这是全部开发人员所追求的。若是有可能，只需需求方本身动动手操做下就完成。

那么该如何提效呢？我所能想到的，大概有：

• 基于各视图层库的具备一致 API 的 UI 框架；
• 可以覆盖整个研发流程的命令行工具；
• 将一份源码编译/转译成不一样目标平台代码的工具；
• 页面数据化并支持可视化搭建的平台。

这几点，每一个展开往深了弄都是颇有价值的事情，须要耗费不少心血，甚至能够做为一个产品或开一家公司了！

前端架构

在继续往下进行以前，先让咱们来稍微探讨下「前端有架构吗？」这个问题。

有架构吗？

「架构」是什么？架构是一组抽象概念，像「人」，像「宠物」，让你没必要关注他是谁，它是什么动物；架构是一张图，让你可以清楚地了解不一样事物是怎么归类的，它们之间是如何联系到一块，如何进行协做的；架构是指导思想，告诉你什么该作、什么不应作，指引你把代码写到正确的地方；架构是一套方法论，让你知道在哪些场景下遇到哪类问题该怎样去解决……

引用维基百科的话——

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.

基于上述描述，若是前端开发只是单纯的静态页面，即只有 HTML 和 CSS，或 JS 只做为添加特效使用，不操做数据，没有通讯，那么能够说「前端没架构可言」。但，如今从事前端开发的人，有几我的的工做是这样的呢？

我想，从事前端开发的你的工做不是作页面，而是应用开发吧？那么，架构就是必不可少的了。你也许会疑惑：「我连这听起来逼格很高的词具体是指啥都不知道，怎么可能会有？！」

之因此无所察觉，是由于你没有刻意去思考并进行架构设计。想一想看，你是不符合如下情形：

• 根据社区里总结的最佳实践，或者与他人交流时受到启发，在开发时将代码逻辑拆分红不一样模块，并将几个具有一些相同特征的模块放到一个目录下；
• 用 Umi 或 Vue 全家桶开发单页面应用。

这两种状况均可以说是使用了分层架构模式，前者是你无心间进行的，后者是人家帮你作好了的。

好的架构？

既然「前端有架构吗？」这个问题的答案是确定的，「什么样的架构是好架构？」就成为了下一个问题。

在说「什么样的架构是好架构？」以前，先插入另一个问题，有兴趣的话能够先行思考下：一个足够复杂的前端框架，与浏览器、操做系统之间有什么相同点？

回归正题。我认为一个好的架构应该是这样的——

帮公司更轻松地赚钱。这点是最重要的，对于一个企业来讲，若是软件不能让本身赚钱，为何要用它？帮助公司赚钱的方式无非就两种，「开源节流」。「开源」比较难，须要了解行业并洞悉商机，对人自己资质的要求过高；「节流」相对就简单了，减小研发投入，即上文所说的「提效」。

第二重要的，就是「稳定」。一个差不离儿的架构，至少得能支撑业务发展三五年吧？虽然公司未必能活那么久。这就须要在作架构设计时可以面向将来：一是业务的将来，二是技术的将来。面向将来的架构必须扩展性好、足够灵活，这样才有可能应对各类业务场景及突如其来的业务变化。

以上是我以为一个好的架构的两个核心标准，每一个点都会牵扯到不少事情，就不在此多说。

在对一个系统进行架构设计时，会用到多种架构模式，如：分层模式、管道和过滤器模式、微内核模式、微服务模式、MVC/MVVM 模式等。在实现时又会用到多种设计模式、数据结构与算法。

所以，要学习并掌握它们，而后根据（潜在）业务目标与（潜在）应用场景去选择最适合的运用到架构设计和框架实现当中。

核心原则

在作前端架构时，我认为该遵照几个基本原则——

第一个是「以不变为中心」。

软件开发的本质就是操做数据，放在 web 开发的场景，后端是存储、获取数据，前端是收集、展现数据。

数据在前、后端流转时，数据的基本形态不会变：基本类型、对象、列表；数据的传输协议也不会变：HTTP、WebSocket。在前端开发中，离它们越远、离 GUI 越近的东西就越容易变。

因此，首先要作的就是梳理出哪些东西是不易变化的，哪些是很容易就变了的。

第二个是「各层皆可替换」。

将根据易变性梳理出的模块按职责进行分层，定义好层与层之间的对接协议（接口）。除了因自身进化须要，对接协议是基本不会变的，也不该去改变。以此为前提，各层实现可在业务须要或技术升级时进行替换。

第三个是「视图层尽量薄」。

视图层的职责是展现数据，理应只有交互逻辑，而大多数前端在写 UI 组件时会掺杂较多的业务逻辑，使视图层变得非常厚重、臃肿。这样一来，业务逻辑不利于复用，也会增长视图层技术的迁移成本。应将业务逻辑进行抽象，并提取到领域层，让视图层保持纯粹。

因为视图层的易变、多样，并想让它尽量薄，最好有什么方式可以增长它访问逻辑层的成本，就像前端只能经过网络请求访问后端同样。

突然想到在作业务开发时有遇到过这种架构，你有印象吗？没错，就是微信小程序！微信小程序的架构是将逻辑层与视图层放到不一样的线程中运行，从而作到了自然隔离，它们之间交流的媒介只有「数据」：

微信小程序是创建在客户端应用提供一些原生能力基础之上的，那么在浏览器中可以达到相同或相似的效果吗？固然能够！浏览器提供原生能力，视图层运行在 iframe 中，逻辑层则在 web worker 里：

觉不以为这很像「微前端」架构——据我理解，简单来讲就是一种可以让不一样技术栈的模块同时运行在浏览器中，它们能够是组件也能够是应用，而且相互之间可以通讯、协同工做的架构模式。

基于这种架构，能够开发出一个相似于浏览器、操做系统的「超级 app」，成为平台级应用。

若是你在平台部门，上文说的也许就是你要面对的事情。

开源项目

前段时间，某厂的前端团队开源了一套组件库，当时我在想：若是作不到比 Ant Design 优秀，开源个组件库的意义在哪？

出自蚂蚁金服的 Ant Design，不管从设计（视觉设计、代码设计，各类设计）仍是从实现来看都已经很优秀了，API 设计十分考究，国内很难有出其右的做品。

若是说在某个视图层技术或某个端没有其对应的实现，与其本身从头造轮子，还不如实现一个在那个视图层技术或那个端的 Ant Design 版本。

以前我一直认为通过几十年的发展，GUI 的交互形式已经相对固定，不太会有什么突破，若是已经存在了一套非常优秀的交互模式库，后来者如果没有什么可以与其抗争的亮点，在竞争上无疑是以卵击石。

直到听到叔叔说：

开放的意义并非代码，而是有自身对交互的理解，若是作不到这点，那开放组件库就没有意义。

一开始没怎么理解这句话的内涵，以后的几天时不时会想到这句话，琢磨其中的含义。以后突然明白了——这不就跟写文章同样吗？！写做难道是为了让别人看到本身的文字？固然不是！是想用文字记录并表达本身对这个世界、人、事、物的理解。难道已经有人写过相同或相似观点的文章，且写得十分好，本身就不能写了吗？固然不是！

原来如此。

其实任何带有创做性质的行为都是同样的，都是经过某个途径来表达本身的思想，写文章是，写代码是，绘画是，作菜也是。正如荒木老师的书上所说——

最近，我要开始作一个「大」项目。实际是前几年就想作的，只不过当时没想好到底要作些什么，但核心理念是一致的——反混沌！连项目名都起好了，就叫「Anti-chaos」。

为何要作这么一个项目？还不是由于前端圈太混乱？虽然与前些年相比稍微好了那么一点，但跟 Java 圈相比，乱太多了。我但愿「Anti-chaos」能成为盘古之斧，劈开混沌，清者为天，浊者为地。

那么「Anti-chaos」要作些什么？就如刚才所说，这是一个「大」项目，由于它基本要覆盖当前前端开发的方方面面。

我并非想开发一个大而全的框架，而是要遵守「反混沌」的思想拆分红多个小项目，每一个都是解决某个固定场景的问题，它们能够组合并扩展成适合某个团队、企业的解决方案，从而使前端开发乃至前端圈变得更加有序。

以前我也是基于相似的想法，想让「前端工程师」这个职业相关的一些事情变得更加标准、有序，然而这件事操做起来实在是太困难了，比安静地写代码难上不知道多少倍，因此目前处于搁置状态。等「Anti-chaos」有所成效以后，再看状况是否重启那个项目吧。

总结

做为前端工程师，在业务部门所能接触到的技术以及眼界的提升是有限的，一是在作业务时用不上什么太前沿的技术，二是业务部门的性质不会容许也没有资源让你作太多深刻的思考和尝试。

要想真正地提高本身的技术能力和眼界，最好仍是去平台部门吧！刚开始时也许会以为很吃力，这是由于你为了适应环境而在进行思惟模式的转变。等你适应了，你就会发觉本身在思考问题时与后端愈来愈接近，也会愈来愈以为不管作前端仍是作后端，所须要的知识和能力是差很少的，只是要解决的问题不一样。

一我的的水平不能用年龄和年限去衡量，要看他有多少经历，都经历过什么。

本文主要阐述了我最近一段时间对前端开发、前端架构以及开源项目等方面的思考及现阶段的理解，不必定对，可是我目前的看法。

正所谓——

参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山仍然是山，看水仍然是水。

以上。