来看看你离前端架构师还有多远？大型前端应用架构设计提纲

哈鲁，我又来了。最近在知乎上有点郁闷，同一个帖子，赞的多骂的也多。原委大致是讨论为什么某v*框架不适合构建大型项目，反正带节奏的人只要三五个字，就有一众人在下面跪舔。今天来聊一聊我的观点：无论是v*还是rea*，都只是大型前端应用中很小的一部分，并不具备完全的不可替代性，讨论完全基于该框架来构建大型项目，是欠妥的。

命题里面最关键的词是“大型”，但凡参与过大型前端应用开发的朋友，都不限于把思维限定在完全基于某个框架的开发。当然，现代前端框架还是有局部的决定作用，一旦技术选型，那么就不得不按照它的编程范式，引入其生态的第三方工具。但是，对于构建“大型”应用而言，更重要的在于架构。可以说架构的好坏，决定了该项目在未来几年中的实际运维成本。而没有参与过大型应用开发的同学，不应该用单体应用的思维以偏概全的设计将要实施的应用。

那么，作为已经有一定经验的前端工程师，你应该如何去思考和设计大型的前端应用呢？接下来，我把自己认知范围内的大型企业应用前端架构设计概要列出来，仅供你参考。纲要如下：

以上只是我想到的架构设计的方面啦，欢迎在下方留言补充～

在我看来，设计大型企业应用前端架构的最核心两方面，在于设计应用的结构和解决业务的复杂性。这两个方面是我认为的重中之重，是具有宏观层面的一览众山小的前置要领。在所有工作之前，不对这两个核心点进行回答，后面所做的所有工作，都会白费，或者都会消耗大量时间精力后反复重来。

应用的结构

或者说应用架构，是从程序的执行层面去看，这个应用怎么启动，怎么让各个部分协调工作，由此引申出来的是，怎么设计才能保证庞大且复杂的业务操作在我的程序运行过程中、开发过程中、设计过程中，不出错。一旦一个应用涉及的业务方面特别多，层次特别深时，其复杂度及难度都是指数级上升。解决的办法，就是我们常说的“解耦”，把庞大的体系拆分开来，把那些不需要依赖于另外一些内容的部分独立出来，我虽然不能保证我这个庞大的系统没有错误，但是我起码能保证在这个局部的系统里，我可以尽可能做到最好，至于后面怎么融合到整套系统中，我可以后面慢慢打磨。就是这么一个思路。符合这一思路的前端架构方案就是微前端，当然，这里的微前端跟微前端框架是两回事，不少人一谈到微前端，马上就某*kun啦巴拉巴拉。通过微前端的架构，我们可以让我们的业务按照一定的边界进行划分，在设计、管理、开发、运维等方面，都可以具有较强的独立性，从而保证一定的自治，实现在庞大的开发体系中，做到有条不紊，循序渐进。

业务的设计

或者说业务架构，是从实现具体需求的角度出发，这个应用的代码层次应该怎么去布局，怎么让业务逻辑、领域对象、业务流转能够更加清晰，避免一个业务反复写，到处写，乱调用，乱实现。在很多前端项目中，项目的设计者（甚至很多项目没有架构）可能根本没考虑这些问题，一上来就是一把梭撸，而没有深刻思考这种业务层面的东西它在代码层次中怎么布局，全凭意识流，写到哪里算哪里。解决的办法就是我们常说的“抽象”，把一个一个的业务梳理出来，用代码表达出来。比如一个财务系统，我要管理资金从哪里来，到哪里去，每一笔钱在流动时都在做什么事，这个事有些什么维度和度量。听上去这好像是后端建模和建库的事。在前端，你也得去做这件事，你得梳理出你负责的业务，并且用代码表达出来，梳理不出业务，你就是在瞎折腾，平日里没啥事，真正遇到问题的时候，一个数据对不上你就哦豁面临毕业风险。这里，我借助DDD的思想，用UML去梳理业务，用建模去抽象化业务，通过分层架构搭建从领域层到应用层的完整前端层次体系。这部分内容，可以阅读我之前发过的文章《复杂企业应用前端架构探索》。其实很多东西，讲来讲去，思想都是不变的。

Ops vs. 规范

人是围绕项目转的，返回来，项目也围绕着人在转。每个人每天工作8小时（^_^想的美😊……）能完成的工作量在有条不紊的状态下和混乱的状态下，是完全两种效率。混乱的状态下，开了3天会，改了两三稿，代码还一行没写。清晰的状态下，喝完咖啡写完代码，还有几个小时不知该如何度过，于是为Oteam贡献一点代码。

我的意思是，架构设计，特指前端架构设计，不是单纯把眼光盯在写代码这点事上，还要兼顾上下游工作过程中，使参与者具有清晰的思维，工作状态有条不紊，即使某些需求看上去非常复杂难搞，但是一旦内心平静，按部就班，那种喝咖啡摸摸带鳞生物的状态还是会有。

从需求收集、整理，设计稿交付，开发启动，前后端联调，测试交付，部署交付，到最终上线跟进。每一个环节做法都可以有所不同，我知道很多人会把“规范”做的非常重，但是我认为重的规范，不如用技术工具解决这其中的交付问题。举个例子，默认情况下，我们会和产品人员对需求，然后按照产品的要求进行设计稿一比一还原，再交由设计师对稿。但在技术加持下，我们可以使用设计稿出码，稿即码，码即稿。再往前一步，设计稿即交互稿，交互稿即设计稿，交互稿由产品人员出，怎么出？通过组建化的设计工具，例如某f*ma平台，组装出自己理想中的界面，再通过平台api调到pipeline上，在仓库中自动创建分支，该分支内即拥有一比一稿码。

我的意思不是每一个项目都需要实现这样的能力，我的意思是，思想不同，做法也就不同，按部就班不是固守陈封，而是在某些东西的加持下，可以做到“他强由他强，清风拂山岗”。这可不是一朝一夕，有的需要花钱去采购，有的需要有强大的队友建设。规范化，流程模式化，这些都在架构设计范围内。

生态建设

大型项目之所以“大”，不仅体现在多、深这两个点，还有一个方面在于业务方往往对系统要求很高，但是给的资源又很少。从工程师的严谨出发，我们不仅要保证“建成”，还要保证“建好、建稳”。

从保证把项目“建好、建稳”的目的出发，我们不仅要设计完成功能开发层的内容，还要设计保证开发过程稳健，开发结果健壮的生态。例如质量体系、测试体系、监控体系、安全体系、性能体系，这些项目的附属生态缺一不可，虽然很多都有现成的工具，但是要整合到已有的开发体系中，而不是分散的随意的。

多端同构

过去几年，随着小程序的崛起，让同一套代码在不同平台上运行成为降低成本的一种重要手段，虽然在探索解决方案的过程中需要消耗巨大的投入，但是一旦建成，就可以无限复用到其他业务中，对于具有众多产品的大公司而言，非常实惠。对于只有单一产品的小公司来说，也是收益不错，因为只需要开发1次，就可以同时得到多个获客渠道，何乐不为呢？

当然，你可能说性能不好啦，体验不好啦，开放中存在很多坑啦。但是，花10块钱买一个鸡腿，再送你一盒薯条，它不香嘛？多端，要保证统一业务实现的一致性，除了使用同一份代码，我想不到有什么可以做到更准确保证业务一致性的方法。

当然，同构的层次也是可以分的，如果没有我最前面讲的两个核心要素，手机端和PC怎么同构？而一旦分层，我们就会发现，手机端和PC端和小程序端，顶多就是视图层（表现层）的不同，但表现层之下的数据层、逻辑层应该保持一致。如果没有优秀的分层架构，把各种数据层逻辑层的东西统统堆到基于某xx框架的所谓store、hooks等等中，那么是不可能做到真正的跨端同构的。

前后端同构

当然，在不同的公司，这还不一定能实践，后端自有后端的架构，以支持某些业务必须的性能要求。但是在一些特定场景下，纯前端是解决不了的，如果用后端服务器来跑任务成本更低，那么它就是一个更优解。

前端即后端，后端即前端，这是前端的一个趋势，也即我们除了需要从数据源拿数据完成交互之外，我们也可能需要从数据源之外的其他资源进行处理以完成业务处理。看上去就是抢后端饭碗嘛？但恰恰相反，我们前面提到微前端，实际上它是一个妥协方案，微前端意味着仍然存在中心化的后端和前端（顶层应用），而无法做到脱离环境的真正独立运行。比微前端更进一步的是，微服务化的前端，或者说是不分前后端的统一业务子服务。它有后端也有前端，统一起来完成该业务，而其他需要它的应用只需要调用它，调用它就同时拥有它的前端和后端。基于serverless和云原生的能力，我们可以基于类似某ne*js框架的服务端渲染能力，同时在服务端调用服务完成数据或资源操作，看上去它只有一个入口，但最终它包含了业务的前后端一起。

而后端的同学，把更多的精力往更后去走。

潮流趋势

新的体验正在悄然诞生，AR、VR、AI、区块链，这些熟悉又陌生的技术在未来必然是应用层面的重要存在载体。虽然我们现在不一定马上就要，但是我们在架构设计时，或许需要留出一些口子，在不久的将来，有可以立即与之对接的能力，这当然也是架构可扩展的要求。

今天讲的有点多，就这样吧。