从事前端开发的你，不知有没有被问过：「前端有架构吗？」
问你的人的身份，可能是你的 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.
Wikipedia Software architecture
基于上述形容，如果前端开发只是单纯的动态页面，即只有 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」有所功效之后，再看状况是否重启那个我的项目吧。
思维总结
作为前端工程师，在业务部门所能接触到的技术以及眼界的进步是无限的，一是在做业务时用不上什么太前沿的技术，二是业务部门的性质不会容许也没有资源让你做太多深刻的思考和尝试。
要想真正地晋升本人的技术能力和眼界，最好还是去平台部门吧！刚开始时兴许会感觉很吃力，这是因为你为了适应环境而在进行思维模式的转变。等你适应了，你就会察觉本人在思考问题时与后端越来越靠近，也会越来越感觉无论做前端还是做后端，所须要的常识和能力是差不多的，只是要解决的问题不同。
一个人的程度不能用年龄和年限去掂量，要看他有多少经验，都经验过什么。
本文次要论述了我最近一段时间对前端开发、前端架构以及开源我的项目等方面的思考及现阶段的了解，不肯定对，然而我目前的见解。
正所谓——
参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山依然是山，看水依然是水。
青原行思
以上。
本文其余浏览地址：集体网站|微信公众号